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Executive  Summary 


Using  Simulation  and  Modeling  in 
Procurement 

The  end  of  the  Cold  War  brought  de¬ 
creased  military  budgets  at  a  time  when 
existing  platforms  and  weapons  were 
reaching  the  end  of  their  service  life.  The 
emergence  of  new  military  missions  and 
technologies  lead  to  a  need  for  revolution 
in  acquisition  strategy.  The  Department  of 
Defense  (DoD)  searched  for  new  ways  to 
improve  the  systems  acquisition  process  to 
meet  the  emerging  need.  Research  con¬ 
firmed  the  nation's  military  needed  the 
means  to  field  new  or  improved  systems 
quickly  and  efficiently  with  reduced  acquisi¬ 
tion  costs. 

This  philosophy,  simplistic  in  its  approach, 
is  rather  complex  in  execution.  In  its  zeal 
to  research,  develop,  test,  and  field  sys¬ 
tems,  a  program  office  must  establish  a 
balance  among  system  capabilities,  speed 
of  acquisition  and  procurement  costs.  This 
balance  is  often  measured  in  the  degree  of 
risk  that  exists  in  meeting  the  objectives 
that  a  proposed  system  is  designed  to 
achieve.  These  objectives  include  per¬ 
formance,  schedule,  and  cost.  DoD  re¬ 
search  conducted  in  the  early  1990's 
concluded  that  practices  and  processes 
using  simulation  and  modeling  practices  in 
procurement  could  increase  the  likelihood 
of  acquiring  and  producing  systems  that 
have  better  performance,  a  faster  schedule 
for  delivery  and  fielding,  and  a  significant 
cost  savings  compared  to  acquisition 
procedures  and  practices  used  during  the 
Cold  War. 


The  use  of  modeling  and  simulation  tools 
enables  a  design  team  to  perform  "what  if' 
analyses  on  hundreds  of  options  and 
provides  rapid  feedback  to  the  design 
engineers  in  charge  of  system  develop¬ 
ment.  In  addition,  Modeling  and  Simulation 
(M&S)  techniques  remain  applicable  to  the 
entire  product  life  cycle.  As  result  of  Joint 
Vision  2010,  DoD  directed  that  acquisition 
program  managers  use  an  M&S  process  in 
future  systems  procurement  programs. 
The  Defense  Modeling  and  Simulation 
Office  (DMSO)  was  tasked  with  assisting  in 
developing  models  and  simulations  that 
support  the  acquisition  process. 

In  2000,  the  Office  of  Naval  Research 
(ONR)  sponsored  development  of  a  proc¬ 
ess  that  used  M&S  tools  and  for  the  first 
time,  linked  both  the  warfighter  and  opera¬ 
tions  analysis  to  the  acquisition  process. 
Warfighting  Concepts  to  Future  Weapon 
System  Designs  (WARCON)  is  one  of  the 
first  Navy  efforts  in  developing  an  effective 
simulation  and  modeling  procurement 
process. 

What  Is  WARCON? 

Conceptually,  the  WARCON  process  links 
requirements  and  capabilities  desired  by 
the  warfighter  with  establishment  of  Meas¬ 
ures  of  Performance  and  Measures  of 
Effectiveness  (MOPs/  MOEs)  for  a  future 
system.  Development  of  models  and 
simulations  based  on  current  capabilities 
support  the  measurement  of  performance 
factors  and  comparison  of  cost  data  to 
obtain  the  rapid  feedback  required  by 
simulation  and  modeling  procurement 
approaches. 
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Why  WARCON?  A  number  of  other  meth¬ 
ods  exist  to  support  procurement  investiga¬ 
tions  and  activities.  Many  have  as  their 
foundation  the  required  M&S  tools  with 
which  to  make  acquisition  decisions,  field 
new  systems,  and  involve  the  warfighter  in 
the  process. 

WARCON  uniquely  provides  a  proven  and 
demonstrated  method  for  linking  operations 
analysis  to  the  warfighter  and  to  the  M&S 
toolset,  while  managing  the  project  in  a 
virtual  environment.  In  addition,  the  WAR¬ 
CON  process  allows  the  decision-maker  to 
provide  a  rapid  response  to  acquisition 
issues  and  a  way  to  link  systems  and 
design  engineers  who  may  be  from  differ¬ 
ent  and  even  competing  firms.  For  exam¬ 
ple,  during  development  of  the  WARCON 
process,  a  linkage  between  North  rop- 
Grumman  Newport  News  Shipbuilding, 
Lockheed-Martin  Corp.  and  ONR  facilitated 
a  trade  study  on  practices  and  products  to 
improve  throughput  of  the  Carrier  Weapons 
Handling  System  (CWHS)  on  Nimitz-class 
aircraft  carriers  for  the  next  generation  of 
platform,  the  CVN-21. 

Depending  upon  the  issue  under  study,  the 
WARCON  process  can  employ  a  synthetic 
battlespace  with  a  range  of  models  across 
a  distributed,  federated,  simulation  net¬ 
work,  enabling  the  warfighter  to  apply 
technological  concepts  to  anticipated 
threats. 

A  Collaborative  Engineering  Enterprise 
(CEE)  permits  the  engineer  to  apply  design 
processes  that  are  cognizant  of  total  life 
cycle  costs  while  satisfying  the  warfighter's 
requirements. 


Using  the  WARCON  process  will  increase 
long-term  effectiveness,  decrease  acquisi¬ 
tion  cycle  time,  and  reduce  Total  Owner¬ 
ship  Cost  (TOC)  of  new  weapon  systems. 
WARCON  achieves  this  through  co¬ 
development  of  operational  concepts  and 
weapon  system  designs  in  an  end-to-end, 
strategy-to-task  collaboration  of  warfight¬ 
ers,  weapon  system  designers,  and  opera¬ 
tions  analysts. 

The  WARCON  process  focuses  on  estab¬ 
lishing  Integrated  Process  Teams  (IPTs) 
and  Virtual  Project  Management  tech¬ 
niques  that  allow  for  the  rapid  tracking  and 
completion  of  the  WARCON  process  for 
participants  in  diverse  organizations  and 
locations.  At  a  minimum,  the  IPT  structure 
includes  an  Operations  Analysis  IPT,  an 
Engineering  Concept  Development  IPT, 
and  a  Modeling  &  Simulation  IPT.  These 
Integrated  Process  Teams  report  to  a 
Management  IPT,  comprised  of  the  Pro¬ 
gram  Manager,  senior  managers,  and 
representatives  from  each  of  the  functional 
IPTs  described  above.  Each  IPT  can 
establish  working  groups  as  needed  for 
specific  tasks. 

The  WARCON  Process 

Six  major  steps  have  been  developed  and 
tested  for  the  WARCON  process  (see 
Figure  1).  WARCON  uses  the  Integration 
Definition  for  Function  Modeling  (IDEFO) 
format  to  depict  and  document  the  generic 
management  process.  WARCON  person¬ 
nel  tailor  these  processes  for  each  specific 
application  depicted  in  Program-specific 
IDEFO  diagrams.  These  diagrams  docu¬ 
ment  the  process  steps  required  in  WAR¬ 
CON,  and  serve  as  a  roadmap  for  the 
IPTs. 
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Figure  1.  The  WARCON  Process 


•  The  WARCON  process  begins  with 
the  Project  Planning  Phase,  shown 
as  Node  A1  in  integration  Definition 
for  Function  Modeling  (IDEFO)  For¬ 
mat  in  Appendix  B. 

•  During  this  time,  the  issue  or  prob¬ 
lem  is  defined,  the  WARCON  proc¬ 
ess  is  tailored  for  this  problem,  func¬ 
tional  IPTs  are  identified,  and  a  Pro¬ 
ject  Management  Plan  is  developed. 
In  addition,  the  management  and 
analysis  plans  reflect  requirements 
and  policies  outlined  in  appropriate 
DoD  documents. 

Operations  Analysis 

The  next  step  in  the  process  is  an  analysis 
of  the  customer  problem  (Appendix  B; 
IDEFO  Node  A2).  Through  the  systematic 
use  of  operations  analysis,  the  user  can 
refine  the  requirements,  including  those 


from  the  warfighter,  in  the  context  of  the 
current  operational  environment.  This 
permits  rapid  inclusion  of  these  changes 
into  the  process  thereby  reducing  devel¬ 
opment  and  testing  costs. 

This  phase  of  the  project  produces  two 
critical  sets  of  metrics.  The  first  set  en¬ 
compasses  Measures  of  Effectiveness 
(MOEs).  These  are  measures  of  success 
based  upon  the  operational  objective 
established  by  the  acquisition  PM.  Exam¬ 
ples  of  MOEs  may  include  number  of 
bombs  on  target  or  strike  response  time. 
The  second  metric  is  a  set  of  Measures  of 
Performance  (MOPs),  which  as  a  subset  of 
MOEs  represent  a  level  of  performance  of 
a  particular  subsystem  or  process  step. 
Examples  of  MOPs  may  include  speed, 
payload,  range,  time  on  station,  or  other 
quantifiable  performance  features. 
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Other  products  of  this  step  include  docu¬ 
mentation  of  the  legacy  system  being 
analyzed  for  the  acquisition  decision,  a 
description  of  one  or  more  scenarios  upon 
which  to  base  models  and  experimentation, 
and  a  survey  of  the  available  technologies 
and  capabilities  under  consideration  as 
candidates  for  the  new  system  that  will  be 
acquired.  In  addition,  because  the  WAR- 
CON  process  can  link  competing  technolo¬ 
gies,  it  can  identify  the  most  cost-effective 
system  that  meets  or  exceeds  established 
requirements. 

The  Problem  Analysis  phase  of  the  proc¬ 
ess  culminates  in  the  development  of  an 
Experiment  Plan.  The  Experiment  Plan 
drives  the  development  of  alternative  or 
“candidate”  engineering  concepts;  a  Model¬ 
ing  &  Simulation  environment  that  will  test 
and  measure  the  concepts,  and  generate 
metrics  that  can  be  analyzed  and  used  to 
make  Trade  Study  Plan.  The  Trade  Study 
Plan  defines  methods  and  tools  for  produc¬ 
ing  a  cost-performance  trade-off  study  of 
system  alternatives  to  be  simulated  in  the 
models.  Operations  Analysis  assesses 
these  results  and  the  metrics  generated  in 
the  model  and  develops  a  Trade  Study 
Report. 

Develop  Engineering  Concepts 

The  concept  development  engineers  use 
the  Experiment  Plan  to  determine  the  gap 
between  the  current  capabilities  of  the 
legacy  system  and  the  objective  system. 
Next,  they  identify  potential  process  im¬ 
provements  and  candidate  technologies 
that  may  satisfy  the  requirements  of  the 
“new”  system,  Methodologies  are  devel¬ 
oped  to  evaluate  and  measure  the  various 
engineering  concept  alternatives  under 


consideration.  Then  they  develop  alterna¬ 
tive  engineering  concepts  for  improving  the 
current  weapon  system  or  developing  a 
new  system  (Appendix  B;  IDEFO  Node  A3). 

Early  identification  of  key  sources  of  critical 
information  supports  flexibility,  accuracy, 
and  maturity  in  all  parts  of  the  WARCON 
process.  Identifying  the  key  sources  of 
critical  information  early  on  reduces  the  risk 
of  choosing  unproven  technologies,  and 
proprietary  systems.  The  engineers  often 
build  models  to  assist  in  designing  the 
system  so  that  it  will  allow  quick,  low  cost 
changes  to  the  system  to  accommodate 
different  concepts  or  changes  to  the  sys¬ 
tem  design.  After  the  engineers  are  satis¬ 
fied  with  their  options  for  alternative  de¬ 
signs,  they  provide  design  data  and  cost 
estimates  to  the  Analysis  IPT  for  inclusion 
in  the  Experiment  and  Trade  Study  Plans. 

Build  Integrated  M&S  Environment 

The  M&S  IPT  uses  the  associated  techni¬ 
cal  data  to  incorporate  these  alternative 
designs  into  the  simulated  operational 
environment  (Appendix  B;  IDEFO  Node 
A4).  It  is  in  this  environment  that  analysts 
and  acquisition  decision  makers  consider 
the  operational  performance  of  the  alterna¬ 
tive  designs  for  the  chosen  operational 
scenarios.  M&S  professionals  choose 
operational  models  and  simulations  to 
optimize  reuse  of  existing  models  if  possi¬ 
ble,  and  to  integrate  models  developed  by 
other  organizations.  Incomplete  knowl¬ 
edge  of  model  capabilities  and  limitations 
can  significantly  affect  other  aspects  of  the 
WARCON  process.  This  is  especially 
important  when  concept  development  and 
M&S  activities  share  the  same  models. 
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The  M&S  IPT  tailors  the  synthetic  compo¬ 
nents  for  each  WARCON  problem  or 
alternative  technology  under  consideration. 
They  may  include  component  models  and 
simulations  for  entities  at  levels  from  joint 
theater-level  warfare  operations  to  individual 
ships  and  aircraft,  or  ground  combat  units 
down  to  the  individual  Marine  or  soldier. 

Key  outputs  for  this  part  of  the  process  are 
operational  performance  measures  for 
each  scenario  and  combinations  of  plat¬ 
forms,  weapons,  and  systems  defined  in 
the  Experiment  Plan.  In  addition,  an  output 
of  this  part  of  the  process  is  a  Verification 
and  Validation  (V&V)  Report  that  verifies 
that  the  models  developed  during  this 
phase  of  the  process  accurately  represent 
system  performance  and  warfare  opera¬ 
tions  for  the  selected  operational  environ¬ 
ments. 

Conduct  Experiment 

After  development  of  the  models  and 
simulations,  the  WARCON  process  pro¬ 
ceeds  to  the  Experimentation  Phase 
(Appendix  B;  IDEFO  Node  A5).  In  this 
phase,  the  M&S  IPT  uses  outputs  of  the 
preceding  phases  (e.g.;  the  Experiment 
Plan,  Hypotheses,  MOEs/MOPs,  and  M&S 
systems)  to  conduct  experiments  and 
excursions  for  the  system  under  study. 
The  warfighter  can  play  a  significant  role 
during  this  part  of  the  process  by  "using" 
the  virtual  system  under  study.  This 
portion  of  the  process  outputs  detailed 
performance  data  for  use  with  baseline  or 
comparison  systems  and  each  experiment 
excursion. 

Develop  Trade  Study 

The  WARCON  process  culminates  in 
developing  and  publishing  a  Trade  Study 


Report  (Appendix  B;  IDEFO  Node  A6). 
This  report  summarizes  project  data  and 
presents  results  of  the  cost/performance 
trade-off  analysis  for  each  alternative 
design.  The  Trade  Study  gives  the  acquisi¬ 
tion  decision-maker  an  assessment  of  the 
TOC  of  the  system  and  each  alternative 
engineering  design.  Where  appropriate, 
the  Trade  Study  can  recommend  to  the 
decision  maker  the  best  system  from 
among  a  group  of  candidate  systems. 

In  some  circumstances,  the  Trade  Study 
may  even  recommend  that  the  production 
or  procurement  of  a  candidate  system 
would  not  be  in  the  best  interests  of  the 
government  based  upon  a  cost-benefit 
analysis.  In  other  words,  the  WARCON 
process  allows  the  decision-maker  to 
decide  not  to  procure  a  system,  or  any 
alternative,  based  on  the  data. 

WARCON  in  the  Simulation  and  Model¬ 
ing  in  Procurement  Process 

WARCON  exceeds  the  basics  of  the 
simulation  and  modeling  procurement 
process  by  enabling  the  decision-maker  to 
render  an  informed,  metrics-based  decision 
in  a  short  amount  of  time.  The  WARCON 
infrastructure  includes  IPTs,  M&S  tools, 
operations  analysis  and  design  methods 
and  models,  which  the  Program  Manager 
can  adapt  and  tailor  for  each  individual 
acquisition  program.  Management  of  the 
program,  and  its  milestones,  are  under  the 
direct  cognizance  of  the  PM  and  the  Man¬ 
agement  IPT  that  the  PM  establishes. 

The  key  advantage  of  the  WARCON 
process  is  the  ability  to  incorporate  the 
warfighter’s  needs  and  operations  analysis 
results  in  decisions  regarding  the  system 
being  procured.  The  results  are  defensible 
because  they  have  integrated  the  three  key 
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process  components:  operations  analysis, 
engineering  concept  design,  and  M&S.  In 
this  way,  the  new  system  will  be  able  to 
meet  projected  requirements  at  the  lowest 
cost  instead  of  being  obsolete  and  cost- 
prohibitive  by  the  time  it  is  introduced  to 
operational  forces. 

Putting  It  All  Together 

An  example  of  how  the  WARCON  process 
works  can  be  seen  in  a  study  performed 
concerning  aircraft  carrier  weapons  han¬ 
dling  systems.  The  current  design  is  based 
on  the  Nimitz-class  aircraft  carrier  devel¬ 
oped  in  the  late  1960's.  The  system  was 
designed  for  standard  ballistic  ordnance, 
an  air  wing  consisting  of  65  combat  aircraft, 
and  an  operational  requirement  to  provide 
continuous  flight  operations  (i.e.;  24-hours 
per  day). 

After  introduction  to  the  fleet,  combat 
aircraft  aboard  the  Nimitz-class  carrier 
increased  to  more  than  80.  This  necessi¬ 
tated  parking  aircraft  on  areas  of  the  flight 
deck  that  covered  the  weapons  elevators, 
thus  rendering  the  weapons  elevators 
useless  for  transporting  built  weapons  to 
the  flight  deck.  Now,  most  of  the  ordnance 
being  transferred  from  the  hangar  deck  to 
the  flight  deck  must  be  moved  using  the 
aircraft  elevators.  This  slows  ordnance 
movement  by  requiring  it  to  be  coordinated 
with  other  aircraft  elevator  movements. 

The  current  vision  for  2010  is  an  air  wing  of 
50  aircraft  armed  with  joint  guided  ("smart") 
weapons.  Guided  weapons  are  generally 
larger  than  their  counterpart  ballistic 
("dumb")  weapons.  The  current  weapons 
elevators  are  inadequate  to  meet  the  high 
demand  of  cyclic  flight  operations  using 
aircraft  armed  with  physically  larger, 
"smart"  weapons. 


Using  the  WARCON  process,  the  analyst 
defines  the  problem  in  several  ways.  The 
first  considers  the  newer  joint  ordnance  (J- 
Weapons)  size  and  adaptations  of  the 
weapons  magazines.  The  second  consid¬ 
ers  the  number  of  aircraft  available  in  the 
2010  air  wing.  The  next  considers  the 
Projected  Operational  Environment  (POE) 
and  how  much  ordnance  needs  to  be 
placed  on  a  target  set  in  a  given  time 
period. 

In  this  case,  the  IPT  structure  of  Manage¬ 
ment,  Operations  Analysis,  Engineering 
Concept  Development,  and  Systems 
Engineering/M&S  personnel  is  well  suited 
to  meet  the  requirements  of  the  study.  The 
concept  development  engineers  have  a 
number  of  technologies  available  for  study. 
In  addition,  existing  flight  deck  and  hangar 
deck  models  can  be  adapted  or  new  ones 
developed  to  represent  ordnance-handling 
operations.  The  Analysis  IPT  defines 
operational  scenarios,  collects  inputs  from 
the  warfighter,  and  defines  weapons 
handling  system  MOPs  and  MOEs.  Ana¬ 
lysts  also  develop  the  Experiment  and 
Trade  Study  Plans. 

The  concept  development  engineers 
survey  the  available  technologies  and 
provide  possible  alternative  concepts.  The 
first  is  to  retain  the  weapons  elevators  as 
currently  designed.  The  second  is  to  make 
structural  changes  that  place  the  weapons 
elevators  in  different  parts  of  the  hull  to 
enable  their  use  on  the  flight  deck  during 
flight  operations.  Data  from  the  resulting 
concept  designs  are  given  to  the  M&S 
group  for  running  within  the  simulated 
environment.  M&S  tools  are  then  pro¬ 
duced  for  performing  experiments.  During 
this  phase,  various  aspects  of  the  problem 
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are  assessed  and  evaluated.  Numerous 
excursions  are  run  and  the  results  are  used 
as  inputs  to  the  Trade  Study. 

The  Trade  Study  adds  cost  data  to  the 
alternative  system  performance  data.  In 
our  example,  it  is  determined  that  the 
baseline  system  (i.e.;  the  elevators  remain 
as  originally  designed)  appears  the  most 
cost-effective  design  for  the  problem.  The 
cost  of  relocating  the  weapons  elevators 
appears  to  be  prohibitive  for  the  existing 
ship  class.  However,  results  of  the  study 
will  be  important  in  the  design  and  place¬ 
ment  of  weapons  elevators  aboard  future 
classes  of  aircraft  carrier. 

Using  the  WARCON  methodology,  the 
entire  end-to-end  process  for  the  weapons 
handling  example  takes  6  to  9  months  to 
complete,  far  less  than  previous  design 
and  acquisition  decision-making  activities. 

Holistic  Overview  of  this  Guide 

The  purpose  of  this  summary  is  to  intro¬ 
duce  the  Acquisition  Manager  to  the 
WARCON  process  and  to  give  the  man¬ 
ager  a  fundamental  understanding  of  how 
the  process  can  be  used  to  help  in  the 
decision-making  element  of  the  acquisition 
process. 

Chapter  1  looks  at  Project  Planning.  One 
of  the  great  advantages  of  the  WARCON 
process  over  other  simulation  and  model¬ 
ing  procurement  processes  is  the  flexibility 
to  tailor  the  process  specifically  to  meet  the 
requirements  of  the  acquisition  program 
under  study.  The  planning  phase  estab¬ 
lishes  the  IPT  structure;  defines  and  refines 
the  Customer  Problem  Statement;  deter¬ 
mines  the  operations  analysis,  engineering 
concept  development  and  systems  engi¬ 


neering  approaches;  and  provides  the 
initial  Management  Plan  for  the  project  as  a 
whole.  This  phase  is  most  critical  in  that  it 
establishes  the  specifics  of  the  problem  or 
required  decision,  tailors  the  process  and 
defines  the  resources  and  time  required  to 
produce  the  Trade  Study  for  the  decision¬ 
maker. 

Chapter  2  provides  specific  guidance  on 
analyzing  the  problem.  The  process 
includes  reviews  of  existing  technologies 
and  models  and  provides  an  assessment 
of  their  suitability  for  use  in  the  current 
project.  Technologies  and  models  already 
in  existence  often  will  be  sufficient  or  can 
be  modified  to  complete  the  project, 
thereby  reducing  the  overall  cost  of  the 
WARCON  assessment.  Scenarios  and 
functional  requirements  for  the  engineering 
concept  development  and  M&S  environ¬ 
ment  are  defined.  Experiment  and  Trade 
Study  Plans  are  developed  and  reviewed 
by  the  customer. 

Chapter  3  is  dedicated  to  assisting  the 
WARCON  user  in  tailoring  the  engineering 
concept  development  and  design  part  of 
the  process  for  the  warfare  system  being 
studied  for  improvement  or  replacement.  It 
discusses  technology  assessment  and 
system  concept  development  and  assess¬ 
ment  processes.  Modeling  tools  to  support 
this  activity  are  also  discussed. 

Chapter  4  is  dedicated  to  building  the 
integrated  M&S  environment  and  produc¬ 
tion  of  the  V&V  Report.  The  models  must 
be  realistic  enough  to  be  relevant  in  the 
current  operational  environment  and  the 
simulations  must  be  sufficiently  rigorous  to 
support  the  MOPs/MOEs,  and  yield  practi¬ 
cal  results. 
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Conducting  the  experiment,  with  baseline 
systems  and  excursions,  is  described  in 
Chapter  5.  The  experiment  is  conducted 
using  inputs  from  the  warfighter  and  the 
major  participants  (i.e.;  design  engineers, 
modelers,  and  analysts)  are  involved. 

A  complete  analysis  of  the  results  is  com¬ 
piled  and  published  for  use  in  developing 
the  Trade  Study  Report,  which  is  discussed 
in  Chapter  6.  The  Trade  Study  provides 
the  cost-benefit  analysis  and  may  make 
recommendations  to  the  Program  Manager 
regarding  what  systems/equipments  to  buy 
or  not  buy.  Explanations  of  TOC  and 
design  alternative  costs  are  included  in  this 
section. 

Chapter  7  discusses  the  Collaborative 
Engineering  Environment  (CEE),  a  power¬ 
ful  management  tool.  The  CEE  provides 
the  methodology  for  virtual  project  man¬ 
agement.  Any  number  of  participants  may 
participate  in  the  WARCON  process.  The 
CEE  allows  the  Program  Manager  to 
manage  the  program  regardless  of  any¬ 
one’s  physical  location.  Tools,  texts,  and 
data  can  reside  within  the  CEE;  this  makes 
program  management  simpler  and  more 
cost  effective.  The  CEE  can  reduce  the 


requirements  for  face-to-face  meetings, 
thus  reducing  travel  funds  expenditure,  and 
can  render  up-to-date  information  on 
tasking  and  project  status  to  members  of 
the  WARCON  team. 

Summary 

The  WARCON  process  is  a  powerful 
decision-support  tool,  which  provides  for 
project  management,  rigorous  determina¬ 
tion  of  cost  and  performance,  and  rapid 
response  to  the  inevitable  "what  if’  ques¬ 
tions  inherent  in  the  procurement  environ¬ 
ment.  In  the  era  of  having  to  buy  more 
systems  for  less  money,  managers  are 
being  required  to  justify  every  decision  they 
make. 

WARCON  is  a  tool  that  enables  the  Pro¬ 
gram  Manager  to  answer  the  barrage  of 
questions  that  come  from  those  who 
control  the  money  while  simultaneously 
providing  the  warfighter  the  most  sophisti¬ 
cated  systems  for  use  on  the  battlefield. 

Given  the  current  threat  environment,  rapid 
fielding  of  improved  systems  helps  the 
United  States  maintain  technical  superiority 
over  her  adversaries. 
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Chapter  1  —  Project  Planning 


"...  [Pjlanning  is  the  process  of  de¬ 
termining  what  needs  to  be  accom¬ 
plished,  by  whom,  when,  and  under 
what  resource  constraints.  It  is  ar¬ 
guably  the  most  important  of  the 
program  management  functions.”1 

WARCON  and  IDEFO 

Initially  developed  by  the  U.S.  Air  Force  in 
the  1970s  and  1980s,  Integration  Definition 
for  Function  Modeling  (IDEFO)  techniques 
are  widely  used  in  government  and  com¬ 
mercial  sectors  to  support  modeling  efforts. 

"IDEFO  models  provide  a  'blueprint' 
of  functions  and  their  interfaces  that 
must  be  captured  and  understood  in 
order  to  make  systems  engineering 
decisions  that  are  logical,  affordable, 
integratable  and  achievable.’2 

The  WARCON  process  uses  IDEFO  tech¬ 
niques  to  provide  flexibility  for  analysis 
support  to  acquisition  decision  makers. 
WARCON  allows  the  customer,  through 
operations  analysis  and  a  collection  of 
models  and  simulations,  to  examine  multi¬ 
ple  technological  options  before  committing 
resources  to  unproven  design  concepts. 

Coordinating  activities  among  organiza¬ 
tions  and  tailoring  the  WARCON  process  to 

1  William  W.  Bahnmaier,  Ed.,  DSMC  -Scheduling 
Guide  for  Program  Managers ,  Defense  Manage¬ 
ment  College  Press,  Ft.  Belvoir,  VA,  Oct  2001 

2  Announcing  the  Standard  for  Integration  Definition 
for  Function  Modeling  [IDEFO],  Draft  Federal 
Information  Processing  Standards  Publication  183, 
Department  of  Commerce,  National  Institutes  of 
Standards  and  Technology,  Gaithersburg,  MD,  21 
December  1993 


support  simulation  and  modeling  based 
analysis  of  a  specific  Customer  Problem 
Statement  are  the  critical  first  steps  in 
applying  the  WARCON  process. 

The  distributive  nature  of  the  WARCON 
process  requires  capturing  the  functions 
and  processes  of  the  various  IPTs  in  a 
single,  coherent  picture.  The  IDEFO 
proved  to  one  successful  method.  How¬ 
ever,  functional  flow  diagrams,  assuming 
they  depict  similar  tasks  and  guidelines, 
may  also  engender  a  satisfactory  organiza¬ 
tion  and  execution. 

Defining  the  Problem 

WARCON  IDEFO  diagrams  provide  a  basic 
tool  for  tailoring  and  managing  the  WAR¬ 
CON  process.  DoD  does  not  envision  a 
"cookie  cutter"  approach  to  weapons 
procurement.  Each  customer  problem 
presents  unique  decision  requirements: 

"There  is  no  one  best  way  to  struc¬ 
ture  an  acquisition  program  so  that  it 
accomplishes  the  objectives  of  the 
Defense  Acquisition  System.  Deci¬ 
sion-makers  and  program  managers 
shall  tailor  acquisition  strategies  to  fit 
the  particular  conditions  of  an  indi¬ 
vidual  program,  consistent  with 
common  sense,  sound  business 
management  practice,  applicable 
laws  and  regulations,  and  the  time- 
sensitive  nature  of  the  user's  re¬ 
quirement.  ,a 

3  DODINST  5000.1;  The  Defense  Acquisition 
System  (Incorporating  Change  1,  January  4,  2001); 
23  October  2000 
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The  first  step  in  developing  a  WARCON 
Project  Management  Plan  (PMP)  is  to 
define  and  refine  the  warfighter  require¬ 
ments  from  the  Customer  Problem  State¬ 
ment  (i.e.,  "What  question  does  the  cus¬ 
tomer  really  want  answered?").  Questions 
become  more  clearly  articulated  problem 
statements,  limiting  the  project  scope. 
Second,  develop  and  list  planning  assump¬ 
tions,  examine  resource  costs,  and  identify 
affected  functional  areas.  Often  there  is 
only  one  problem  or  issue  under  considera¬ 
tion.  However,  there  are  times  when  a 
customer  has  a  number  of  problems  or 
issues  related  to  the  acquisition  decision. 
In  these  cases,  a  review  of  the  available 
resources  (e.g.,  personnel,  tools,  funding) 
is  necessary  and  those  resources  balanced 
against  the  problems. 

For  example,  if  a  customer  has  12  unre¬ 
lated  systems  requiring  upgrade  or  re¬ 
placement  and  the  funding  level  for  the 
WARCON  process  is  only  $2  million  for  the 
fiscal  year,  the  PM  must  determine  how 
much  of  the  process  can  be  accomplished 
given  these  constraints.  Since  model 
development  traditionally  requires  a  signifi¬ 
cant  fiscal  outlay,  the  realistic  answer  may 
be  to  scale  back  the  process  to  accomplish 
all  process  steps  leading  to  model  devel¬ 
opment. 

New  concepts  can  bring  paradigm  changes 
that  depart  from  currently  accepted  prac¬ 
tices.  The  process  requires  considering 
ideas  in  an  unconstrained  environment, 
which  leads  to  defining  working  hypothe¬ 
ses.  It  is  important  all  participants  remain 
open-minded  and  resist  accepting  or 
rejecting  initial  ideas  or  hypotheses  early  in 
the  process.  Participants  need  to  remem¬ 
ber  that  just  because  something  is  being 


investigated,  does  not  imply  it  is  being 
advocated. 

Defining  the  problem  shapes  the  entire 
WARCON  process.  Providing  the  PMP  to 
the  WARCON  team  early  in  the  process 
focuses  the  IPTs  and  various  corporate 
and  government  entities  on  the  warfighter’s 
problem,  and  the  measurements  used  to 
assess  the  possible  solutions.  The  teams, 
with  delineated  lines  of  responsibility 
knowledge  of  milestones,  remain  free  to 
coordinate  their  activities  and,  if  necessary, 
forward  potential  conflicts  to  the  Manage¬ 
ment  IPT  for  early  interventions  and  solu¬ 
tions. 

Tailoring  the  WARCON  Process 

A  clear  understanding  of  the  customer 
problem  is  required  to  tailor  the  WARCON 
process  effectively.  The  Analysis  IPT 
leads  the  tailoring  effort,  but  all  members  of 
the  Management  IPT  must  participate. 
This  guide  is  one  resource  for  tailoring  the 
process.  Other  resources  include  lessons 
learned  and  publications  from  previous 
WARCON  projects,  and  professional 
papers  and  presentations  made  by  WAR¬ 
CON  practitioners.  As  other  programs 
employ  the  WARCON  process,  a  central 
repository  for  WARCON  results  would  be 
beneficial. 

What  factors  should  direct  the  tailoring 
process?  Clearly,  the  time  and  resources 
available  for  the  project  are  limiting  factors. 
Other  factors  may  include: 

•  If  the  problem’s  focus  is  related  to 
systems  improvements,  process  im¬ 
provements,  or  both 
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•  The  anticipated  availability  of  existing 
technologies  for  system  improve¬ 
ments  that  will  assist  in  determining  if 
concept  development  will  focus  on 
designing  new  systems  or  assessing 
existing  Commercial  off  the  Shelf 
(COTS)  or  Government  off  the  Shelf 
(GOTS)  technologies 

•  Availability  of  knowledge  and  data  on 
the  existing  system  or  process  for 
studying  the  baseline 

•  The  anticipated  availability  of  models 
that  can  be  federated  with  reasonable 
changes,  or  whether  extensive  new 
model  development  will  be  required 

•  The  anticipated  availability  of  data  to 
support  determination  of  total  owner¬ 
ship  costs  for  alternative  solutions 

•  Whether  experiments  are  anticipated 
to  include  participation  of  warfighters 
or  other  users  as  part  of  the  experi¬ 
ment  design 

•  The  anticipated  degree  to  which  the 
customer  is  expected  to  be  an  active 
participant  in  the  process 

•  The  anticipated  relative  amount  of 
time  and  resources  required  for  each 
major  part  of  the  WARCON  process. 

IPT  Functions  and  Project 
Planning 

The  WARCON  PM  defines  the  organiza¬ 
tional  structure.  Since  the  key  WARCON 
functions  are  Operations  Analysis,  Engi¬ 
neering  Concept  Development,  and  Sys¬ 
tems  Engineering,  it  makes  sense  to 
identify  IPTs  and  group  leads  for  each 
function.  Management  IPT  membership 


usually  includes  the  PM  and  the  Group 
Leads.  The  Management  IPT  tailors  the 
process  for  each  customer  problem,  devel¬ 
ops  the  Project  Management  Plan  (PMP), 
and  generally  directs  and  oversees  the 
entire  project.  The  Management  IPT  uses 
the  PMP  to  address  configuration  man¬ 
agement  practices  (including  adjudication 
of  issues)  for  all  project  documents. 

The  PM  charges  the  Analysis  IPT  with 
formalizing  the  Customer  Problem  State¬ 
ment  and  identifying  an  overall  approach 
for  applying  the  WARCON  process.  The 
Analysis  IPT  then  makes  recommendations 
for  tailoring  the  WARCON  process  to 
integrate  operations  analysis,  concept 
development,  and  M&S  to  assess  perform¬ 
ance  and  TOC  of  future  systems  or  system 
improvements  for  use  in  the  Trade  Study. 
The  Analysis  IPT  submits  these  recom¬ 
mendations  and  a  draft  Trade  Study  Plan, 
evaluating  potential  solutions  to  the  cus¬ 
tomer’s  problem,  to  the  Management  IPT 
for  approval. 

The  Engineering  Concept  Development 
IPT  does  a  first  look  at  new  concepts  and 
technologies  for  system  improvement 
during  the  Project  Planning  phase  of 
WARCON.  They  determine  whether 
system  solutions  are  available  using  off  the 
shelf  sources,  or  develop  new  systems  and 
concepts  to  address  potential  solutions  to 
the  customer  problem. 

The  Systems  Engineering  Group  then  uses 
this  assessment  to  select  or  develop  the 
M&S  tools.  Examples  of  decisions  that  this 
Group  must  resolve  for  WARCON  partici¬ 
pants  include  whether  models  will  be  self 
contained  at  a  single  location  on  a  Local 
Area  Network  (LAN)  or  geographically 


MTS  Technologies,  Inc. 


11 


For  Official  Use  Only 


distributed  at  multiple  locations  over  a 
Wide  Area  Network  (WAN).  Occasionally, 
M&S  tools  may  include  the  end  users’ 
participation. 

The  Management  IPT  authorizes  the 
federation  architecture  and  overview  of 
models  and  simulation  to  be  used  to 
support  the  analysis.  Simulations  must 
provide  useable  information  to  the  cus¬ 
tomer  and  satisfy  validation  requirements. 
Not  every  purchase  or  new  product  re¬ 
quires  a  significant  investment  in  M&S  and 
analysis.  Maximum  reuse  of  existing 
models  is  a  key  part  of  the  WARCON 
process. 

It  is  often  possible  to  modify  an  existing 
model  for  application  to  a  new  WARCON 
problem.  As  part  of  the  M&S  approach, 
existing  M&S  standards  are  used  where 
practical.  Properly  applied,  M&S  standards 
reduce  cost  by  providing  approved  solu¬ 
tions  to  common  problems.  Examples  of 
such  standards  encompass  authoritative 
algorithms  and  models;  interoperability 
standards  for  simulations,  command  and 
control  systems,  and  data  interchange 
standards.4 

For  example,  a  decision  to  upgrade  to  a 
different  desktop  computer  for  routine 
administrative  requirements  should  not 
require  an  extensive  M&S  program  with  a 
detailed  action  list  and  assigned  responsi¬ 
bilities.  However,  deciding  on  a  cockpit 
upgrade  for  an  F/A-1 8  would  lend  itself  to 
extensive  experimentation  and  analysis. 
WARCON  works  best  for  complex  acquisi- 


4  DoD  5000.2-R;  Mandatory  procedures  for  Major 
Defense  Acquisition  Programs  (MDAPS)  and  Major 
Automated  Information  Systems  (MAIS),  10  June 
2001 


tion  projects  that  require  significant  techno¬ 
logical  investments. 

Successfully  applying  the  WARCON 
process  requires  integrated  planning  and 
coordination  among  government,  engi¬ 
neers,  M&S,  and  analysis  organizations. 
Models  and  Simulations  that  support  an 
acquisition  decision  must  represent  capa¬ 
bilities  ranging  from  concept  design  and 
technology  assessment  to  operational 
effectiveness. 

Armed  with  an  understanding  of  operations 
analysis,  concept  engineering,  and  sys¬ 
tems  engineering  components  of  the 
tailored  WARCON  process,  the  PM  can 
develop  a  project  Work  Breakdown  Struc¬ 
ture  (WBS).  The  WBS  provides  a  coordi¬ 
nated  and  comprehensive  view  of  tasks 
required  to  complete  the  process.  It  links 
products  to  financial  and  technical  re¬ 
sources.  It  is  oriented  to  a  particular 
product  and  can  be  detailed  to  any  level  of 
interest.5  Figure  2  is  a  sample  WBS. 

On  any  given  WARCON  project,  it  is  likely 
that  the  major  IPTs/Groups  will  be  working 
simultaneously.  Cooperation  and  coordi¬ 
nation  among  teams  and  individuals  exer¬ 
cising  functional  responsibility  is  para¬ 
mount. 

The  Plan  of  Action  and  Milestones 
(POA&M)  is  a  crucial  management  tool  that 
ensures  the  integrated  WARCON  process 
is  on  track  from  cost,  schedule,  and  per¬ 
formance  viewpoints.  It  details  the  steps 
required  to  meet  deliverables,  on  time  and 
on  budget  and  provides  sufficient  lead-time 
to  account  for  coordinating  inputs  and 
submissions  from  the  various  groups. 

5  MIL-HDBK-881 B  of  02  January  1998 
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Figure  2.  Sample  Work  Breakdown  Structure 


Effective  scheduling  supports  the  following 
key  management  activities:6 

•  Provides  the  basis  for  communica¬ 
tions  within  the  government  team 
and  with  contractors 

•  Identifies  a  baseline  for  program 
status  monitoring,  reporting,  and 
program  control 

•  Facilitates  management 

•  Establishes  a  foundation  for  re¬ 
source  analysis,  alternatives  explo¬ 
ration,  and  trade-off  studies 

The  Groups  need  to  work  in  conjunction 
with  each  other,  yet  autonomously  identify 
and  resolve  issues  and  make  independent 
decisions  within  their  areas  of  responsibil¬ 
ity.  Depending  on  the  issue  complexity, 
the  Group’s  size,  and  the  members’  per- 


6  William  W.  Bahnmaier 


sonalities,  a  team  may  require  several 
months  to  reach  optimal  effectiveness. 

The  PM  must  create  a  structure  to  facilitate 
these  interactions;  not  only  among  Groups, 
but  also  among  matrix  organizations 
supporting  the  WARCON  process.  The 
PM  must  build  the  flexibility  to  allow  the 
various  teams  to  meet  POA&M  plateaus 
but  still  account  for  program  activity  and 
funding. 

Project  Management  Plan 

Though  additional  coordination  remains, 
the  POA&M  assigns  responsibility  and 
provides  a  scheduling  framework.  The  PM, 
after  resolving  initial  organizational  issues, 
examines  the  resources  available  for  the 
project.  This  input  provides  the  Manage¬ 
ment  Group  the  necessary  information  to 
formulate  the  Project  Execution  Plan,  and 
then  disseminate  it  to  the  WARCON  part¬ 
ners. 
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This  internal  document  contains  the  data 
needed  for  realistic  cost  and  delivery 
estimates.  After  the  customer  accepts  the 
cost,  the  Management  IPT  agrees  upon  the 
Project  Management  Plan  (PMP).  This 
provides  overarching  guidance  to  the 
remaining  phases  of  the  WARCON  proc¬ 
ess. 


Summary 

The  Project  Management  Plan  provides  the 
requisite  guidance  to  the  WARCON  teams. 
In  addition  to  a  scheduling  POA&M,  this 
document,  accepted  by  all  participants  and 
the  customer,  establishes  organizational 
responsibility,  realistic  delivery  and  cost 
schedules,  and  the  key  analysis  approach 
and  M&S  architecture,  it  also  provides  the 
flexibility  to  continue  to  fine-tune  the  tai¬ 
lored  WARCON  process. 
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Chapter  2  —  Analyze  Problem 


Operations  Analysis  plays  a  critical  role  in 
the  WARCON  process.  The  WARCON 
process  uses  analysis  linked  to  M&S  to 
reduce  the  time,  resources,  and  risks 
associated  with  systems  acquisition  while 
also  increasing  quality.  Virtual  prototypes 
in  a  synthetic  environment  allow  assess¬ 
ment  of  future  systems  through  various 
stages  of  the  development  process. 

The  Project  Planning  process  includes 
development  of  the  general  problem 
statement  and  analysis  approach  in  order 
to  tailor  the  WARCON  process,  plan 
resources,  and  develop  a  Project  Man¬ 
agement  Plan.  Now  the  problem  statement 
and  approach  must  be  defined  in  detail  so 
that  experimental  hypotheses,  performance 
measures,  and  Experiment  and  Trade 
Study  Plans  can  be  developed  (Appendix 
B;  IDEFO  Node  A2). 

Refine  the  Requirements  in  Detail 

A  successful  acquisition  program,  whether 
designed  to  counter  new  threats  or  replace 
obsolete  systems,  must  deliver  supportable 
and  capable  systems  to  the  warfighter. 

Given  this  background,  The  Analysis  IPT 
proceeds  to  the  first  step  in  the  decision- 
support  process  -  a  functional  analysis  of 
existing  systems  and  warfare  processes  as 
they  relate  to  mission  and  other  customer 
desires.  The  objective  of  such  an  analysis 
is  to  define  the  requirements  a  new  or 
upgraded  system  must  satisfy  to  address 
the  Customer's  Problem  Statement.  The 
WARCON  analysis  process  links  the 


National  Military  Strategy  Document 
(NMSD),  the  current  Defense  Planning 
Guidance  (DPG)  and  other  formal  require¬ 
ments  to  the  warfighter’s  operational 
needs. 

Analytic  definition  of  the  customer  problem 
occurs  during  Project  Planning.  For  exam¬ 
ple,  if  the  customer  tasked  WARCON  to 
find  out  if  an  aircraft  carrier  air  wing  could 
service  a  given  number  of  targets  in  24 
hours,  analysts  might  redefine  this  problem 
as  "Determine  the  conditions  under  which 
a  set  number  of  targets  could  be  serviced 
in  24  hours."  This  represents  an  ideal 
issue  for  the  WARCON  process:  it  is 
complex  and  amenable  to  technological 
solutions  and  warfare  process  improve¬ 
ments. 

The  problem  statement  however  needs 
significantly  more  detail  before  beginning  a 
functional  analysis.  Analysts  must  first 
identify  conditions  that  are  important,  such 
as  air  wing  composition  and  weapons  load, 
target  type  and  distribution,  scenario, 
environmental  conditions  and  threats.  In 
doing  so,  the  analysts  place  the  issue 
under  study  in  an  operational  context. 

Experimental  hypotheses  are  derived  from 
a  combination  of  the  detailed  problem 
statement  and  the  high-level  solution  set  of 
concepts  developed  during  Project  Plan¬ 
ning.  A  hypothesis  describes  a  set  of  facts 
that  can  be  tested  by  experimentation  in  an 
"if.. .then"  formulation.  They  define  combi¬ 
nations  of  conditions  to  be  examined 
during  experimentation. 
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Each  experiment  should  test  one  or  more 
hypotheses  that  relate  directly  to  the 
Customer  Problem  Statement.  In  WAR- 
CON  experiments,  hypotheses  are  framed 
in  terms  of  impacts  on  operational  effec¬ 
tiveness. 

Hypotheses  may  examine  alternative 
design  or  warfare  concepts  using  a  variety 
of  assumptions,  constants,  limitations,  and 
conditions.  In  order  to  test  the  hypotheses, 
build  an  integrated  M&S  environment,  and 
plan  for  information  extraction,  the  Systems 
Engineering  Group  must  know  the  data 
creation  and  collection  needs.  These 
requirements  are  discussed  in  the  following 
section. 

Define  M&S  System  Functional 
Requirements 

When  presented  an  acquisition  decision  for 
a  system  that  is  open  to  a  technical  solu¬ 
tion,  analysts  and  systems  engineers  must 
first  study  the  problem  to  determine 
whether  an  appropriate  M&S  environment 
already  exists.  If  not,  they  need  to  decide  if 
appropriate  M&S  tools  could  be  designed. 
The  WARCON  Systems  Engineer  selects 
or  builds  models  based  on  the  M&S  system 
functional  requirements  defined  by  the 
Analysis  Group  (Appendix  B;  IDEFO  Node 
A2.2). 

The  Customer  Problem  Statement  and 
detailed  problem  definition  are  the  basis  for 
M&S  functional  requirements.  They  are 
unconstrained  by  M&S  availability  or 
design  limitations  of  future  systems.  They 
include  M&S  capabilities  needed  to  ad¬ 
dress  various  aspects  of  the  customer 
problem.  Functional  requirements  may 
include  detailed  warfare  process  models, 


technical  characteristics  of  future  aircraft  or 
ships,  system  engineering  data,  or  detailed 
scenario  and  virtual  warfare  concepts  and 
operations  simulations. 

As  functional  requirements  evolve, 
changes  require  rigorous  management  and 
clear  documentation.  They  should  be 
easily  accessible  to  all  participants  and 
tracked  in  an  electronic  database.  Numer¬ 
ous  commercial  tools  exist  to  facilitate  this 
process.  Program  management  should 
investigate  these  tools  and  plan  for  them  in 
the  program  budget. 

Meeting  all  of  these  M&S  functional  re¬ 
quirements  may  not  be  possible  within  the 
available  WARCON  project  resources.  In 
addition,  some  M&S  technical  require¬ 
ments  may  be  unavailable  or  pose  signifi¬ 
cant  risk  to  project  completion. 

The  Problem  Definition,  Scenario,  and 
M&S  Systems  Requirements  Document  lay 
out  the  unconstrained  requirements  for 
assessment  by  systems  engineers  and 
concept  development  engineers  for  feasi¬ 
bility  within  project  constraints.  These 
constraints  must  be  factored  into  the  M&S 
system  functional  requirements  before  the 
Experiment  and  Trade  Study  Plans  can  be 
drafted.  Soliciting  inputs  from  Subject 
Matter  Experts  (SMEs)  provides  another 
method  of  determining  weapon  system 
functional  requirements. 

Management  must  convey  the  customer's 
objective  for  the  project  and  the  constraints 
contained  in  the  problem  statement  to 
SMEs.  The  SME’s  role  requires  clear 
definition  to  ensure  proper  use  of  this  asset 
and  to  schedule  the  SME’s  presence  (if 
required)  during  the  experiment  phase. 
Experience  proves  early  SME  participation 
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and  frequent  SME  consultation  returns 
favorable  results  as  the  WARCON  pro¬ 
ceeds  through  its  natural  steps. 

Experiment  Assumptions  and 
Limitations 

A  balanced  analysis  includes  clearly 
defined  assumptions  and  limitations. 
Without  stipulating  these  details,  analysis 
results  lose  valid  references  and  contexts 
for  the  decision  maker.  In  other  words, 
assumptions  and  limitations  provide  a 
context  for  interpreting  experimental  re¬ 
sults.  For  example,  in  determining  if  a  new 
weapon  system  will  meet  targeting  expec¬ 
tations,  the  analyst  must  consider  assump¬ 
tions  made  such  as;  expected  adversary 
defenses,  the  distance  the  weapon  must 
travel  from  the  launch  platform  to  the 
target,  and  external  support  (e.g.,  aircraft 
tanking  or  logistics). 

A  model's  credibility  for  use  depends  upon 
the  relevance  of  specific  factors.  There¬ 
fore,  analysts'  reports  must  explicitly 
identify  operational  and  engineering  as¬ 
sumptions.  These  assumptions  provide 
the  starting  point  for  any  analysis  project. 
The  WARCON  process  analysts  must  also 
address  an  experiment's  limitations.  For 
example,  models  may  be  limited  in  their 
ability  to  change  weather  or  lighting  condi¬ 
tions.  Other  limitations  may  include  in¬ 
complete  technical  data  regarding  the 
studied  system  (e.g.,  fuel  capacity).  Some 
of  these  limitations  may  affect  the  value  of 
the  data  derived  from  conducting  the 
experiment. 

Modeling  software  contains  inherent 
limitations  clearly  identifiable  by  the  devel¬ 
oper/programmer.  Other  external  factors 


may  limit  an  experiment’s  fidelity  (e.g.,  the 
need  to  keep  the  results  unclassified).  In 
other  words,  limitations  exist  in  models  and 
simulations.  Effective  decisions  require  full 
cognizance  of  these  limitations.  At  a 
minimum,  the  experiment  should  realisti¬ 
cally  represent  valid  doctrine  and  specifi¬ 
cally  address  each  aspect  of  the  Customer 
Problem  Statement. 

Experiment  Plans 

The  Experiment  Plan  (Appendix  B;  IDEFO 
Node  A2.3.2)  includes  explicit  procedures 
for  conducting  the  WARCON  experiment. 
An  experiment's  effectiveness  is  bounded 
by  realism  within  previously  identified 
constraints.  The  Analysis  Group  cannot 
design  an  experiment  until  it  receives  High 
Level  Design  (HLD)  input  from  the  Systems 
Engineering  Group  and  preliminary  de¬ 
scriptions  of  concepts  or  systems  to  be 
assessed.  The  HLD  and  Alternative 
Concept  Descriptions  present  the  informa¬ 
tion  analysts  need  to  make  workable 
Experiment  and  Trade  Study  Plans  from 
the  unconstrained  requirements  of  the 
Problem  Definition,  Scenario,  and  M&S 
Systems  Requirements  Document. 

Analysis  requires  a  thorough  review  of 
cause-and-effect  relationships  among  a 
series  of  variables.  An  experiment  plan 
allows  the  Analysis  Group  to  trace  chang¬ 
ing  variables  to  differing  results.  Control¬ 
ling  variables  offers  the  additional  flexibility 
of  post-scenario  analysis  to  determine 
resource  limitations  that  may  require 
adjustments  from  current  practices.  When 
the  customer  proposes  a  solution  possibly 
open  to  an  industrial/technical  solution,  the 
Analysis  Group  needs  to  determine  the 
state  of  current  and  projected  technologies. 
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An  assembly  of  analysts  and  design  engi¬ 
neers  collaborate  to  form  the  Knowledge 
Acquisition/Engineering  (KA/E)  Group. 
This  group  will  complete  a  Technology 
Survey  to  define  the  baseline  conditions 
used  in  the  experiment,  provide  baseline 
and  comparison  data,  and  assist  the 
analysts  in  determining  whether  current 
procedures  and  systems  fulfill  the  needs 
identified  by  the  warfighter. 

The  KA/E  group  also  determines  if  the 
necessary  technology  will  be  available  in 
time  for  insertion  into  the  acquisition  deci¬ 
sion-support  process.  If  not,  the  KA/E 
develops  a  logic  tree  that  demonstrates  the 
necessary  excursions,  technology  trials, 
and  outcomes  sought  when  developing  the 
new  technology.  The  Analysis  Group 
clearly  identifies  data  extraction  and  collec¬ 
tion  requirements  in  the  Experiment  Plan. 
Planned  excursions  to  an  experiment 
provide  a  means  for  correlating  results  to 
engineering  design  changes.  The  Experi¬ 
ment  Plan  also  lists  the  models  and  capa¬ 
bilities  likely  required  for  an  experiment's 
simulations. 

In  addition  to  data  extraction  and  collection 
requirements,  an  experiment's  critical 
outputs  include  MOPs  and  MOEs.  The 
MOPs  can  be  derived  from  or  roll  up  to 
MOEs.  For  example,  an  MOE  for  a  fuel- 
efficient  vehicle  may  be  an  ability  to  drive, 
fully  loaded,  from  Washington,  DC  to 
Tampa,  FL  on  one  tank  of  fuel.  One  MOP 
may  be  that  the  vehicle  range  must  be  at 
least  1 ,000  miles. 

Initial  experiment  excursions  must  be 
defined  for  each  set  of  experiment  runs 
designed  to  investigate  a  single  variable  or 
question.  The  Draft  Experiment  Plan 
defines  the  objectives,  hypotheses,  scenar¬ 


ios,  MOPs/MOEs,  analysis  methods,  data 
extraction  and  collection  requirements  and 
methods,  and  procedures  for  conducting 
the  WARCON  project  experiment. 

Running  a  baseline  experiment,  based 
upon  current  configurations,  will  yield 
anticipated  (i.e.,  "real-world")  output  data. 
When  dissimilar  results  appear,  possible 
causes  include  incorrect  calibration  or 
inaccurate  assumptions.  The  baseline  also 
provides  a  starting  point  for  MOPs  and 
MOEs.  MOPs  and  MOEs  provide  the 
quantitative  measures  that  characterize 
operational  performance  and  effectiveness 
for  the  modeled  excursions  and  scenario. 
The  MOPs  and  MOEs  are  defined  in  the 
Draft  Experiment  Plan,  prior  to  conducting 
the  experiment,  to  identify  data  extraction 
points.  These  measures  also  determine  if 
feedback  from  any  individual  excursion  will 
change  follow-on  tests. 

Engineering-level  models  indicate  perform¬ 
ance  capabilities,  or  MOPs.  MOPs  charac¬ 
terize  physical  or  functional  attributes 
relating  to  execution  of  the  mission  or 
function.  In  other  words,  an  MOP  provides 
an  indicator  of  achievement,  such  as  radar 
acquisition  range,  or  time  to  move  aircraft 
from  the  hangar  deck  to  the  flight  deck. 
These  parameters  may  be  used  in  system 
design  specifications. 

Each  MOP  should  focus  on  meeting  the 
customer's  needs.  They  quantify  a  techni¬ 
cal  or  performance  requirement  directly 
derived  from  the  MOE.  Therefore,  the 
compilation  of  MOPs  determines  the  MOE. 
An  MOE  is  an  output  from  mission  and/or 
battle  level  models  and  simulations,  and  is 
an  indicator  of  how  well  the  system  per¬ 
formed  the  customer's  mission. 
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The  WARCON  process  is  most  effective 
when  measuring  outcomes  using  a  variety 
of  repeatable  scenarios.  These  "excur¬ 
sions"  use  the  same  scenario  (save  for  the 
variables  being  examined  in  the  excursion) 
to  provide  comparable  data.  These  may 
include  Order  of  Battle,  warfare  operations, 
and  periods.  Modeling  scenarios  may  run 
at  various  speeds  (e.g.,  faster-than-real- 
time)  as  long  as  the  model's  run  speed 
does  not  adversely  affect  the  human 
element's  ability  to  react  to  the  state  of  the 
system  and  adequately  assess  the  infor¬ 
mation. 

If  supported  by  the  M&S  environment,  the 
results  obtained  from  running  the  baseline 
model  of  the  legacy  system  in  the  simula¬ 
tion  model  early  in  the  process,  can  pro¬ 
vide  useful  information  for  the  concept 
development  process.  These  baseline 
model  runs  can  also  support  validation  of 
newly  developed  modeling  environments. 
It  is  the  Management  IPT's  responsibility  to 
determine  early  in  the  process  whether 
there  are  sufficient  resources  available  to 
perform  baseline  runs  of  the  legacy  system 
in  the  same  M&S  environment  that  will  be 
used  to  conduct  the  experiment. 

The  WARCON  Analysis  Group  determines 
what  data  are  required  and  when  that  data 
are  to  be  collected  during  the  experiment. 
This  could  be  in  the  form  of  questionnaires, 
after-action  reports,  or  running  data- 
extraction  tapes  through  another  simula¬ 
tion.  Detailed  data  extraction  protocols 
ensure  common  responses  and  minimize 
variations  between  subjects  and  reviewers. 
Information  obtained  during  the  experiment 
should  support  MOP  and  MOE  evaluations 
as  well  as  serve  the  baseline/comparison 
and  excursion  cases. 


In  many  M&S  systems,  the  After  Action 
Review  System  (AARS)  can  archive  prede¬ 
termined  computations  for  later  analysis. 
This  system  can  identify  the  situations  and 
excursions  in  order  to  determine  an  MOP. 
Human,  equipment,  tactical,  geographic, 
and  equipment  variables  may  be  recorded 
and  compared  for  later  analysis. 

Once  the  Analysis  Group  identifies  data 
extraction  requirements  for  the  Integrated 
M&S  System,  the  excursions  used 
throughout  the  experiment  should  cause  an 
adjustment  to  the  variables  to  prove  (or 
disprove)  the  hypothesis  and  to  determine 
MOPs  based  upon  changing  inputs. 

Now,  the  Analysis  Group  should  choose 
comparison  methods,  develop  and  quantify 
the  criteria  for  comparison,  and  determine 
appropriate  weighting  factors.  The  appro¬ 
priate  models  and  methods  dictate  the 
objectivity  and  repeatability  of  the  experi¬ 
ment. 

Trade  Study  Plans 

Trade  studies  identify  desirable  and  practi¬ 
cal  alternatives  among  requirements.7 
Technical  objectives,  design,  program 
schedule,  functional  and  performance 
requirements,  and  life  cycle  costs  are 
identified  and  conducted.  Chapter  7 
discusses  the  final  WARCON  Trade  Study 
in  detail. 

The  Trade  Study  supports  comparison  of 
alternative  design  options  through  a  visual 
depiction  of  relevant  operational  perform¬ 
ance  and  cost  metrics  in  a  top-level  format 

7  Systems  Engineering  Fundamentals,  Defense 
Systems  Management  College  Press,  Fort  Belvoir, 
VA,  December  1999,  U.S.  Government  Printing 
Office,  Washington,  D.C. 
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that  can  be  decomposed  to  show  underly¬ 
ing  detail.  The  visual  depictions  represent 
the  "trade  space  region"  (shown  in  Figure 
3)  with  the  objective  and  baseline  require¬ 
ment  values  for  the  various  MOPs  and 
MOEs. 


Region  of  Acceptability 


Figure  3.  Example  of  Trade  Space  Region 


The  WARCON  process  needs  to  manage 
the  documents,  people,  organizations, 
products,  and  data  to  provide  a  logical 
transition  of  information  from  the  M&S 
domain  to  the  production  facility.  Trade 
Study  plans  provide  information  on  how  to 
present  experiment  results  to  a  decision 
maker.  They  include  discussions  of  the 
selection  criteria  and  methods  for  calculat¬ 
ing  TOC. 

Analysts  require  tools  to  perform  detailed 
trade-off  analysis  of  alternate  system 
designs  and  solutions.  Opting  for  alterna¬ 
tive  solutions  requires  postulations  of  all 
potential  ways  of  solving  the  customer 
problem  and  selecting  those  that  appear 
viable.  Trade-off  relationships  should  be 
relevant  and  rational.  Evaluating  the 
alternatives  forms  the  heart  of  the  analysis 
portion  of  the  Trade  Study. 


The  analysts  may  review  and/or  revise  the 
methodology  if  minor  modifications  in  input 
data  affect  the  solution.  The  analyst  does 
not  make  recommendations.  Rather  the 
tools  and  the  Trade  Study  provide  a  range 
of  options  upon  which  the  warfighter  makes 
a  decision.  Relevant  and  validated  data¬ 
bases  support  evaluation  decisions. 

Customer  Review 

Before  proceeding,  the  Analysis  Group 
provides  the  Draft  Experiment  Plan  and 
Draft  Trade  Study  Plan  to  the  customer  for 
review.  This  ensures  that  the  plans  cor¬ 
rectly  reflect  the  customer  problem  state¬ 
ment.  Problem  statement  complexity, 
coupled  with  the  M&S  assumptions  and 
analysis  definitions,  may  change  from  initial 
task  to  experiment  execution.  Changes 
must  be  accounted  for  before  moving  to 
the  experimentation  phase  (Appendix  B; 
IDEFO  Node  A5). 

Conclusion 

After  the  customer  completes  the  review  of 
the  drafts,  the  Analysis  IPT  can  promulgate 
the  final  Experiment  Plan  and  Trade  Study 
Plan.  The  former  is  forwarded  to  the 
Engineering  Concept  Development  and 
M&S  teams  to  build  the  models  and  incor¬ 
porate  appropriate  data  extraction  points. 
The  focus  of  the  Experiment  Plan  is  on 
measuring  performance  of  future  system 
alternatives.  In  addition,  the  Experiment 
Plan  identifies  resources,  objectives, 
analysis  methods  and  input  data  require¬ 
ments. 

The  Trade  Study  Plan  summarizes  project 
data  requirements,  with  a  focus  on  TOC 
data,  and  presents  methods  for  producing 
the  performance-cost  trade-off  analyses  for 
each  option  assessed  using  the  model. 
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Chapter  3  —  Develop  Engineering  Concepts 


Analysis  performed  in  IDEFO  Nodes  A1 
and  A2  (Appendix  B)  refined  the  Customer 
Problem  Statement  and  analysis  approach. 
This  chapter  discusses  IDEFO  Node  A3 
(Appendix  B),  the  development  of  engi¬ 
neering  concepts  and  associated  costs. 

In  this  step  of  the  WARCON  process, 
engineers  must  identify  and  develop 
alternative  systems  and/or  concepts  to 
meet  warfighter  requirements,  and  propose 
engineering  solutions  to  the  Customer 
Problem  Statement. 

Engineering  concepts  determine  the 
physical  characteristics  and  associated 
TOC  for  each  of  the  proposed  concept 
systems.  Detailed  design  data  support 
modeling  of  potential  solutions  in  the 
Integrated  M&S  Environment.  The  Trade 
study  uses  TOC  data  derived  for  each 
system  alternative. 

Using  the  Project  Management  Plan  and 
the  resources  available  to  the  design 
activity,  Engineers  develop  a  body  of 
coherent  and  complimentary  system 
requirements.  These  engineering-level 
functional  requirements  are  then  transi¬ 
tioned  into  physical  requirements  for 
designs  that  can  be  used  to  produce 
material  entities  that  can  be  priced.  Engi¬ 
neering-level  models  often  are  used  to 
provide  estimates  for  both  material  and 
non-material  costs. 

TOC  includes  acquisition  costs,  Operation 
and  Support  (O&S)  costs  for  the  life  of  the 
system  and  disposal  costs  at  the  end  of  the 
system's  lifetime.  O&S  costs  include 
operations,  maintenance,  labor,  and  other 
direct  system  support  costs. 


Determining  the  Capabilities  Gap 

The  problem  operationally  defined  by  the 
Analysis  Group  is  analyzed  in  engineering 
terms.  This  redefinition  involves  establish¬ 
ing  engineering  capabilities  of  the  baseline 
system;  positing  an  ideal  or  objective 
system  that  serves  as  a  goal  to  achieve; 
quantifying  the  difference  between  the 
baseline  capabilities  and  objective  (called 
the  capability  gap);  and  finally,  deriving  a 
set  of  quantified  engineering  level  require¬ 
ments  to  meet  ideal  or  objective  system 
capabilities. 

Determining  the  capability  gap  (Appendix 
B;  IDEFO  Node  A3.1)  for  the  future  system 
begins  with  the  Problem  Definition,  Sce¬ 
nario  and  Functional  Requirements  pro¬ 
vided  by  the  Analysis  Group.  SMEs  de¬ 
termine  the  general  operation  for  IPTs  to 
examine  in  engineering  terms.  SMEs,  with 
first-hand  experience  and  knowledge  of  the 
subject  system  and  its  operation,  identify 
the  individual  activities  involved.  Depend¬ 
ing  on  the  problem,  key  attributes  of  each 
activity  (e.g.,  time  to  execute,  workload 
required,  equipment  used,  facilities  re¬ 
quired,  etc.)  are  established.  If  SMEs  are 
not  readily  available,  conduct  data  acquisi¬ 
tion  by  observation  of  operations  as  they 
take  place  in  the  field. 

Not  all  SMEs  derive  the  same  conclusions 
to  solve  a  given  customer  problem.  The 
PMP  should  establish  a  formal  process  to 
ensure  resolution  of  conflicts  among  SME 
inputs  and  consistency  of  SME  inputs 
among  IPTs. 
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SMEs  provide  a  significant  input  to  the 
developing  an  Engineering  Process  Map. 
This  map  is  an  engineering  level  flowchart, 
detailing  the  activities  and  events  involved 
with  the  operation  under  study.  The  map 
presents  a  functional  baseline  that  deter¬ 
mines  the  limits  of  the  existing  system 
(e.g.,  how  fast,  how  much,  with  what 
workload,  etc.). 

Concurrently,  Substance-Field  Diagrams 
are  developed.  These  diagrams  provide 
an  object-oriented  view  of  the  system 
under  study.  These  diagrams  are  useful  in 
finding  and  selecting  technology  options 
that  may  improve  the  system.  Process 
Maps  and  Subject  Field  Diagrams  define 
present  baseline  limitations  in  capabilities. 
Stating  these  limitations  in  terms  of  conflict¬ 
ing  system  characteristics  defines  System 
"Bottlenecks." 

SMEs,  engineers,  and  analysts  expound 
upon  a  series  of  "what  if  investigations  to 
move  the  query  beyond  the  current  system 
and  its  limitations.  "If  I  could  remove  a  limit 
that  is  keeping  me  from  achieving  greater 
capability,  what  greater  capability  should  I 
achieve  before  I  come  upon  the  next 
limitation"?  All  involved  should  remember 
that  investigation  of  a  concept  is  not  an 
endorsement  of  that  concept.  Conflicts 
among  SMEs  and  concept  development 
personnel  generally  result  from  reluctance 
to  accept  concepts  that  lead  to  paradigm 
shifts. 

The  Desired  Functional  Capabilities  de¬ 
lineates  the  functional  capabilities  that  the 
engineers  must  address.  Differences 
between  baseline  capabilities  and  the 
desired  functional  characteristics  of  the 
objective  system  can  now  be  determined 


using  quantitative  metrics.  Desired  values 
of  the  metrics  are  compared  to  baseline 
quantities  (using  ratios)  to  establish  quanti¬ 
tative  criteria  for  concept  acceptability.  A 
Gap  Measures  Report  provides  the  docu¬ 
mentation  for  this  effort. 

Identifying  Potential  Innovation 
Concepts 

Conflicts  between  current  and  objective 
capabilities  are  resolved  by  making  asso¬ 
ciations  with  alternative  solutions  (Appen¬ 
dix  B;  IDEFO  Node  A3.2).  Before  this  can 
take  place,  technology  information  is  mined 
from  industry  and  DoD  sources,  and 
deposited  into  a  Research  and  Develop¬ 
ment  (R&D)  roadmap  for  the  project.  Tools 
and  techniques  are  available  to  bring  the 
technology  search  out  of  the  simple  "brain¬ 
storming"  mode  and  into  a  more  disciplined 
realm.  Technologies  in  the  R&D  database 
are  grouped  and  organized  into  a  classifi¬ 
cation  system  analogous  to  the  functional 
requirements.  Similar  categorizations  for 
requirements  and  technologies  facilitate 
associations  between  the  two  sets  of  data. 

Technological  solutions  in  the  R&D  Data¬ 
base  are  rated  for  their  completeness, 
feasibility,  and  relevance.  Their  prospect 
for  becoming  part  of  a  real  system  is 
estimated.  This  effort  supports  the  even¬ 
tual  estimate  of  risk  of  a  Concept  System  in 
the  final  decision  analysis. 

Technology  mining  and  requirements 
development  proceed  independently  of  one 
another.  One  may  precede  the  other,  or 
both  may  be  conducted  concurrently. 
Thus,  it  is  desirable  to  devise  a  categoriza¬ 
tion  scheme  before  either  activity  starts  to 
assure  compatibility. 


MTS  Technologies ,  Inc. 


22 


For  Official  Use  Only 


Selecting  Alternative  Engineering 
Concepts 

Technologies  in  the  R&D  Database  are 
sources  of  potential  solutions  for  meeting 
engineering  requirements  for  the  future 
improved  system  (Appendix  B;  IDEFO 
Node  A3.3).  Technologies  are  coupled  to 
requirements  in  a  Technologies-to- 
Requirements  Matrix  colloquially  known  as 
the  "Concept  Box"  (shown  in  Table  1). 
Candidate  technologies  that  fulfill  a  re¬ 
quirement  are  so  marked  in  the  matrix. 

Table  1.  Example  Technologies-to- 
Requirements  Matrix 


Concept  Box 

New  Elevator  technologies 

Use  of  Unobtainlum  alloys 

New  accounting  practices 

Human  Amplification 

Elevator  Speed  shall  be  3x 
faster. 

Assembly  costs  shall  be  less. 

Reliability  shall  be  much 
greater. 

Ship  fitters  lift  more  than 

Arnold  S. 

The  weight  shall  be  reduced 

h 

The  linked  requirements  and  technologies 
form  a  body  of  valid  specifications  and 
associated  relevant  technologies.  The 
technologies  that  best  satisfy  the  require¬ 
ments  can  now  be  selected. 

The  selected  technologies  form  constitu¬ 
ents  of  a  concept  system.  The  Concept 
System  architecture  develops  as  the 


constituents  integrate  into  one  cohesive 
idea.  The  engineer  uses  experience  and 
prudent  engineering  practice  to  bring  the 
disparate  individual  technologies  together. 
An  Initial  Concept  Schematic  represents 
the  fundamental  architecture  of  the  Con¬ 
cept  System. 

It  is  desirable  to  conceive  of  at  least  three 
Concept  System  alternatives  to  support 
later  decision-making.  Defining  these 
alternatives  presents  options  involving 
greater  and  lesser  variants  about  the  focal 
concept.  A  Parameter  Design  phase  is 
entered  after  determining  a  Concept 
System's  architecture  in  which  system 
variables  are  balanced  with  one  another  to 
achieve  a  "best"  solution.  Parameter 
design  quantifies  what  the  Concept  System 
architecture  qualifies. 

Complex  engineering  projects  demand 
specialized  knowledge  from  a  variety  of 
disciplines.  Specialists  come  together  to 
exchange  information  and  negotiate 
agreements.  This  "Engineering  Environ¬ 
ment"  includes  a  system  of  individual 
rights,  protocols,  and  institutional  relation¬ 
ships  for  disciplined  business  conduct. 

A  "Concept  Investigation  Environment 
(CIE)"  facilitates  communications  between 
disparate  parties.  Initially  in  a  CIE,  engi¬ 
neers  working  for  distinct  organizations  act 
in  coordination  by  bringing  their  collective 
expertise  to  bear  on  the  evolving  Concept 
System. 

The  Concept  Engineers  develop  calcula¬ 
tion  routines  (i.e.,  models)  for  calculating 
the  significant  characteristics  of  the  Con¬ 
cept  System  for  the  component  of  which 
they  are  cognizant.  Types  of  models  that 
may  be  developed  include: 
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•  SME  Input  models 

•  Vendor  Input  models 

•  System  Characteristics  Calculations 

•  Acquisition  Cost  Estimators 

•  Reliability  Estimators 

•  Performance  Estimators 

•  Life  Cycle  Cost  Estimators 

•  Staffing  Estimators 

The  models  are  subsequently  linked 
together  in  a  manner  determined  by  the 
Engineering  Concept  Development  IPT, 
but  firmly  managed  by  a  project  leader.  A 
Concept  Investigation  Environment  appli¬ 
cation  is  the  software  that  brings  together 
the  respective  applications  upon  which  the 
models  reside. 

Details  of  the  links  are  elaborated  through 
the  CIE.  Interfaces  are  precisely  docu¬ 
mented.  This  is  constructed  to  protect  any 
proprietary  knowledge  that  exists  between 
models. 

Engineering  and  cost  models  may  be 
developed  at  different  geographic  loca¬ 
tions.  It  is  highly  desirable  to  be  able  to 
integrate  the  models  remotely.  Integrating 
models  over  a  WAN  dictates  some  re¬ 
quirements.  Strict  requirements  exist  for 
transmitting  information  that  is  sensitive  but 
unclassified.  With  data  flowing  over  public 
networks  such  as  phone  lines  or  the  inter¬ 
net,  a  Federal  Information  Processing 
Standard  (FIPS140-1)  certified  encryption 
device  is  required  to  handle  sensitive  but 
unclassified  data.  A  Virtual  Private  Net¬ 
work  (VPN)  may  be  needed  to  satisfy  the 
requisite  security  requirements. 


Handling  classified  data  poses  still  more 
requirements.  Government  supplied 
encryption  devices  will  be  necessary. 
Government  entities  must  also  ensure  that 
networked  sites  meet  minimum  require¬ 
ments,  and  the  networks  must  be  regularly 
inspected.  Mechanisms  such  as  Secret 
Defense  Research  and  Engineering  Net¬ 
work  (SDREN)  and  Secret  Internet  Proto¬ 
col  Router  Network  (SIPRNET)  are  avail¬ 
able  to  transmit  government-classified 
data. 

Once  brought  together,  the  CIE  is  exer¬ 
cised  as  individual  design  parameters  are 
varied  and  a  balance  between  them  is 
found  to  arrive  at  a  “best  solution.”  After 
the  final  Concept  System  solution  is  deter¬ 
mined,  the  CIE  provides  some  persistent 
data  that  allows  the  work  to  be  reviewed,  or 
expanded  upon  by  others  in  the  future. 

The  primary  output  of  this  CIE  effort  should 
be  the  significant  physical  characteristics 
necessary  for  developing  dynamic  models 
and  simulations,  as  well  as  rough  order-of- 
magnitude  material  scopes  for  cost  and 
staffing  estimates. 

The  intent  here  is  not  actually  to  design  a 
working  system,  but  only  develop  a  system 
concept  to  the  extent  necessary  so  that  the 
requisite  data  may  be  obtained. 

Developing  Engineering 
Alternative  Concepts 

Concept  System  data  developed  by  the 
engineering  effort  is  brought  into  a  cohe¬ 
sive  package  for  promulgation  to  M&S  and 
Trade  Study  functions  in  the  WARCON 
process  (Appendix  B;  IDEFO  Node  A3.4). 
A  Concept  Engineering  Package  is  devel- 


MTS  Technologies,  Inc. 


24 


For  Official  Use  Only 


oped  for  each  Concept  System  alternative 
developed  by  the  engineering  effort.  This 
package  presents  the  Engineering  Data  for 
Alternative  Designs. 

The  package  consists  of: 

•  A  Concept  Schematic 

•  Software  design  documents 

•  A  Material  List 

•  Final  Engineering  Process  Maps 

•  A  System  Description 

•  A  Concept  System  Specification 

•  Concept  prospects  for  realization 

Cost  Data  for  each  alternative  system  is 
presented  in  a  separate  document.  Truth 
in  negotiation  requirements  often  restrict 
release  of  cost  information.  Common 
practice  is  for  cost  data  that  could  be  used 
in  price  negotiation  to  be  produced  and 


held  only  by  the  entity  authorized  to  nego¬ 
tiate  costs.  This  is  seldom  the  engineer. 
Engineers  usually  deal  with  only  relative 
costs  to  conduct  comparative  studies. 

Handling  of  such  cost  information  by 
unauthorized  sources  can  cause  complicity 
in  establishing  sound  costs,  possibly  giving 
rise  to  litigation. 

Cost  information  that  may  support,  or  may 
be  construed  to  support,  negotiations  is 
usually  provided  only  when  specifically 
required  by  contract.  These  issues  are 
addressed  by  the  PM  and  customer  during 
Project  Planning. 

Engineering  Data  for  Alternative  System 
Designs,  and  the  Cost  Data  for  Alternative 
Systems,  are  provided  to  the  Analysis 
Group  for  use  in  the  next  process  phases 
of  M&S,  Experimentation,  and  finally  Trade 
Study  analysis. 
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Chapter  4  —  Build  Integrated  M&S  Environment 


Using  an  Integrated  M&S  Environment  for 
assessing  performance  of  alternate  system 
designs  is  an  essential  element  of  the 
WARCON  process.  Building  an  M&S 
Environment  includes  planning,  designing, 
implementing,  and  testing  the  federation  of 
models  and  simulations  to  meet  require¬ 
ments  established  in  the  Experiment  Plan. 

Planning  the  Modeling  and 
Simulation  Environment 

The  Experiment  Plan  places  a  number  of 
functional  requirements  on  the  M&S  envi¬ 
ronment: 

•  Experiment  objectives  to  be  satisfied 

•  Data  extraction  and  collection  re¬ 
quirements 

•  Scenarios  to  be  developed  and  ex¬ 
amined 

•  Explicit  guidelines  defining  how  the 
experiment  will  be  run 

•  The  Integrated  M&S  Environment 
must  incorporate  models  of  alterna¬ 
tive  designs. 

It  is  likely  that  available  models  can  satisfy 
many  of  these  requirements.  Still  more 
may  be  attainable  by  modification  of  exist¬ 
ing  codes.  Maximizing  reuse  of  existing 
models  is  a  significant  factor  in  reducing 
the  cost  of  applying  the  WARCON  process 
when  using  models  and  simulations  to 
facilitate  a  procurement  decision.  The 
System  Requirements  Document  (SRD) 
codifies  requirements  for  the  integrated 
system.  This  document  may  include 
engineering  design,  software  development, 


warfare  operations,  and  cost  models  and 
simulations  required  for  in  designing  and 
building  the  M&S  Environment. 

Engineering  models  can  become  quite 
complex.  In  a  distributed  engineering 
environment  having  multiple  entities  wish¬ 
ing  to  maintain  propriety  over  their  proce¬ 
dures  and  data,  a  centralized  hub  adminis¬ 
tered  by  one  entity  may  not  be  acceptable. 
Phoenix  Model  Center  works  through  a 
centralized  hub,  and  does  not  facilitate 
peer-to-peer  security. 

Alternatives  such  as  those  offered  by 
Technosoft®  may  overcome  this  issue;  they 
are  currently  being  explored  by  the  WAR¬ 
CON  Management  IPT. 

Technosoft®  links  KA/E  and  development 
of  business  rules  into  a  software  package. 
These  efforts  may  overcome  proprietary 
concerns,  offer  peer-to-peer  security,  and 
exponentially  increase  the  speed  at  which 
these  occur. 

Generating  a  qualitative  definition  of  the 
concept  may  require  significant  time.  The 
issues  involved  may  be  arrangement 
specific  and  involve  the  basic  architecture 
of  the  concept. 

Designing  the  Modeling  and 
Simulation  Environment 

A  System  Subsystem  Specification  (SSS) 
database  identifies  the  hardware  and 
software  specifications  and  requirements  to 
design  the  system  as  derived  from  the 
SRD. 
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Analysis  of  the  design  information  (con¬ 
cept,  description,  and  cost)  for  each  alter¬ 
native  subject  system  determines  its 
acceptability.  To  obtain  accreditation  for 
their  intended  purpose  the  model,  simula¬ 
tion,  or  federation  of  models  must  meet  a 
set  of  established  standards. 

When  mapping  System  Requirements 
Specification,  the  overriding  constraints 
are;  (1)  the  design  derives  from  "real  world" 
capabilities,  (2)  the  model  meets  all  re¬ 
quirements,  and  (3)  it  provides  for  trace- 
ability  during  system  design,  implementa¬ 
tion,  and  testing.  A  key  to  creating  accu¬ 
rate  models  is  identifying  model  constraints 
early  in  the  development  phase.  It  is 
important  to  establish  a  standard,  formal 
method  of  capturing  and  communicating 
engineering/SME  data  among  IPTs.  This 
process  is  fundamentally  iterative  in  nature. 

Continuing  the  process  leads  to  creation  of 
a  High  Level  Design  (HLD)  which  de¬ 
scribes  the  major  components  and  how 
they  fit  together  in  the  M&S  environment. 
A  design  can  afford  certain  capabilities 
while  curtailing  others,  so  it  is  important  to 
understand  the  system’s  rough  design  in 
order  to  gain  better  understanding  of  what 
is  feasible  for  the  system  to  simulate.  The 
M&S  IPT  provides  preliminary  HLD  infor¬ 
mation  to  the  Analysis  IPT  during  devel¬ 
opment  of  the  Experiment  Plan  to  ensure 
model  can  generate  data  within  resource 
and  technological  constraints  during  the 
project  timeline. 

Further  decomposition  of  the  HLD  pro¬ 
duces  the  Detailed  Design  Document.  This 
document  details  what  codes  need  to  be 
written  or  modified,  and  how  for  the  soft¬ 


ware  developers  working  on  the  M&S 
environment. 

The  System  Test  Document  details  how  to 
test  the  created  or  modified  codes  to 
ensure  that  they  adhere  to  the  detailed 
design,  and  it  details  testing  criteria  for  the 
environment  as  a  whole.  This  part  of  the 
testing  procedure  ensures  that  the  system 
meets  the  requirements  in  the  SRD. 

Implementing  and  Testing  the 
Modeling  and  Simulation 
Environment 

Guided  by  the  Detailed  Design  document, 
software  engineers  produce  the  vision  of 
the  design  effort.  As  with  design,  there  are 
many  styles  of  implementation,  and  here 
the  only  constant  is  that  the  implementation 
satisfies  the  test  plan. 

Two  types  of  testing  take  place  in  this 
phase:  unit  testing  and  system  testing. 
Unit  testing  consists  of  ensuring  that  the 
design  has  been  properly  implemented. 
Every  component  that  has  been  created  or 
modified  is  tested  to  be  sure  it  does  exactly 
what  it  is  supposed  to  do.  If  a  code  per¬ 
forms  computations,  the  computations  are 
verified.  If  a  code  is  supposed  to  produce 
output  in  a  certain  manner,  the  output  is 
scrutinized  for  format  errors. 

System  testing  ensures  the  system  as  a 
whole  is  functioning  as  expected.  Systems 
of  codes  often  have  many  subtle  interac¬ 
tions.  Unforeseen  side  effects  may  appear 
when  systems  are  modified.  This  suite  of 
tests  is  designed  to  illuminate  any  of  these 
unforeseen  effects  before  the  experiments 
begin. 
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A  design  perfectly  implemented  does  not 
always  achieve  what  the  design  intended. 
The  system  test  will  test  the  M&S  environ¬ 
ment  against  the  System  Requirements 
Document,  to  ensure  that  the  M&S  envi¬ 
ronment  performs  as  required. 

After  this  activity  is  completed,  several  key 
elements  are  in  place: 

•  A  tested  M&S  environment  that 
meets  WARCON  experimentation 
needs 


•  An  M&S  Inventory  of  codes  that  can 
be  used  in  future  modeling  and 
simulation  endeavors 

•  Clear  instructions  on  how  to  use  the 
environment  in  the  proposed  ex¬ 
periment 

•  Validation  and  Verification  Report, 
which  lends  credence  to  the  M&S 
environment  and  any  experiments 
performed  within  it. 
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Chapter  5  —  Conduct  Experiment 


After  development  of  the  models  and 
simulations,  the  WARCON  process  begins 
the  Experimentation  phase.  During  this 
part  of  the  process,  the  products  of  preced¬ 
ing  efforts  coalesce  and  provide  the 
framework  for  conducting  experiments  to 
examine  performance  for  the  base  line  and 
excursions  on  the  system  under  study. 

What  is  Involved  in  Conducting  an 
Experiment? 

An  experiment  is  an  operation  or  process 
employed  to  resolve  an  uncertainty.  A 
successful  experiment  provides  the  neces¬ 
sary  rigor  to  satisfy  the  requirements  set 
forth  in  the  Project  Management  and 
Experiment  Plans.  It  details  performance 
and  cost  data  for  each  excursion  event. 

The  Experiment  Phase  can  be  broken 
down  into  a  three-step  process.  First, 
identify  requirements  and  resources  nec¬ 
essary  to  conduct  the  experiment  (Appen¬ 
dix  B;  IDEFO  Node  A5.1).  Then  run  the 
model  using  current  practices  and  proc¬ 
esses  to  develop  a  baseline  for  comparison 
with  experiment  data.  The  Engineering 
Concept  Development  IPT  uses  the  base¬ 
line  data  to  identify  bottlenecks  in  the 
process.  Accordingly,  it  is  necessary  to  run 
a  baseline  as  early  as  feasible  in  the 
project  and  make  the  baseline  data  avail¬ 
able  to  the  Engineering  Concept  Develop¬ 
ment  IPT. 

After  establishing  a  baseline,  the  IPTs 
conduct  the  experiment  using  previously 
explored  alternatives.  The  teams  review 


the  data  to  ensure  there  is  sufficient 
information  for  a  Trade  Study  analysis. 

Additional  Planning 

The  early  WARCON  process  formulates 
three  documents:  Project  Management 
Plan,  Experiment  Plan,  and  Trade  Study 
Plan.  Together  these  documents  provide 
the  basis  on  which  the  experiment  is  built. 
The  experiment  is  the  critical  element  in 
the  WARCON  process  because  it  provides 
performance  data  for  subject  system 
alternatives  for  use  in  the  Trade  Study.  A 
successful  experiment  requires  detailed 
scheduling  and  an  execution  plan  for  use 
within  an  acceptable  M&S  Environment. 

A  successful  experiment  depends  upon  the 
orchestration  of  resources.  Resource 
elements  should  include  event  times, 
people,  funds,  facilities,  hardware,  software 
and  connectivity  requirements,  as  well  as 
mission  level  simulations  used  for  experi¬ 
mentation  and  analysis.  Early  identification 
of  good  Reliability  &  Maintainability  sources 
databases  is  critical  to  good  Reliability  and 
Life  Cycle  Cost  numbers.  Investigate  and 
identify  tools  to  manipulate  Reliability, 
Maintenance,  and  Availability  (RMA)  data 
early  in  the  process  and  make  recommen¬ 
dations  to  the  Management  IPT  on  the 
feasibility  of  purchasing  tools.  A  compila¬ 
tion  of  this  information  contributes  to  the 
development  of  an  experiment  Concept  of 
Operations  (CONOPS)  document. 

The  CONOPS  document  provides  events 
sequencing  to  support  the  Experiment 
Plan.  An  experiment  execution  schedule  is 
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drafted  to  guide  the  CONOPS.  This 
schedule  lays  out  the  timeline  for  the 
resources  required  in  performing  the 
experiment,  including  availability  of  system 
engineers,  analysts,  SMEs,  and  modeling 
and  simulation  runs  for  the  experiment. 

Experiment  Execution 

Before  running  an  experiment,  the  experi¬ 
ment  team  (analysts  and  systems  engi¬ 
neers  and  M&S  engineers)  conducts  a 
review  of  the  Experiment  Plan  and  the 
CONOPS  (Appendix  B;  IDEFO  Node  A5.2). 
This  is  done  to  ensure  that  any  last-minute 
scheduling  changes  or  resource  limitations 
have  been  taken  into  consideration. 
Additionally,  this  review  identifies  con¬ 
straints  and  undesirable  variables  that 
could  unfavorably  affect  the  execution  or 
the  excursion  run  data. 

Based  on  this  review,  the  Experiment 
Execution  Plan  is  refined  if  necessary. 
Care  must  be  exercised  to  ensure  that 
solutions  to  remedy  any  exposed  difficul¬ 
ties  are  not  at  the  expense  of  the  Experi¬ 
ment  Plan's  guidance. 

Case  Runs 

Establishment  of  an  initial  reference  point 
is  essential  in  any  experiment.  "Before  you 
know  where  you  are  going,  you  must  first 
know  where  you  are.”  A  baseline  experi¬ 
ment  run,  usually  based  on  current  system 
or  process  capabilities,  is  done  for  each  set 
of  variables  to  provide  the  foundation  on 
which  subsequent  excursions  are  com¬ 
pared.  It  is  established  by  using  the  Inte¬ 
grated  M&S  tool. 


The  baseline/comparison  case  runs  take 
into  consideration  all  the  variables  that  are 
defined  in  the  Experiment  Plan.  The 
analysts  perform  a  quick-look  data  analysis 
on  the  baseline/comparison  run  output  data 
to  determine  the  need  for  any  fine-tuning  of 
input  variables  or  additional  excursions.  If 
additional  testing  is  necessary,  which  is  not 
in  conflict  with  the  Experiment  Plan,  the 
refined  data  becomes  input  data  in  the  next 
baseline  data  production  run  for  case 
comparison. 

Collecting  and  reviewing  the  data,  and 
subsequent  testing,  continue  until  experi¬ 
ment  data  requirements  have  been  met  for 
establishing  a  baseline/  comparison  case. 
Excursion  case  runs  of  the  variables  are 
designed  to  test  the  parameters  set  forth  in 
the  Experiment  Plan  and  CONOPS. 

Quick-look  Analysis 

Analysts  and  M&S  personnel  review  the 
results  of  excursion  case  runs  to  determine 
if  the  experiment  data  requirements  have 
been  satisfactorily  met,  or  if  additional  runs 
are  necessary.  A  quick-look  examination 
of  the  results  of  each  model  run  helps  to 
refine  input  data  for  the  next  run.  Analysts 
also  check  the  output  data  to  ensure  that 
the  results  "make  sense"  for  each  run  as  it 
occurs  and  in  the  context  of  other  M&S 
results. 

Even  though  the  quick-look  examination 
can  indicate  when  data  gathered  is  suffi¬ 
cient  for  review,  the  Experiment  Plan 
remains  the  controlling  document.  There¬ 
fore,  the  Experiment  Plan  should  allow  for 
minor  on-site  experiment  parameter  ad¬ 
justments  if  called  for  by  the  quick-look 
analysis. 
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Conclusion 

The  analysts  evaluate  the  experiment  case 
data  as  it  relates  to  the  Experiment  Plan's 
MOE  and  MOP  requirements  (Appendix  B; 
IDEFO  Node  A5.3).  Using  validated  analy¬ 


sis  methods,  the  Analysis  Group  compiles 
performance  and  cost  information  for  each 
alternative  solution  tested.  These  data  are 
analyzed  in  detail  to  support  development 
of  the  Trade  Study  Report. 
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Chapter  6  —  Develop  Trade  Study 


WARCON  Process  and  Trade 
Studies 

A  Trade  Study  is  required  to  support 
acquisition  decisions  presented  by  the 
WARCON  process.  The  Trade  Study 
Report,  summarizing  project  analysis  and 
cost-performance  trade-offs  for  each 
improved  system  alternative,  is  the  final 
product  of  a  project  using  the  WARCON 
system  to  reach  an  acquisition  decision. 


ment  to  weigh  engineering  level  trade-offs 
in  system  design  and  associated  costs. 
These  methods  are  used  again  during  the 
final  step  of  the  WARCON  process  to 
assess  cost-performance  trade-offs  among 
alternative  system  concepts  and  any 
process  improvements  that  were  part  of  the 
experiment  conducted  in  the  simulation 
model. 

Making  Defensible  Choices 


Trade  Studies  have  been  used  in  a  number 
of  manufacturing  and  acquisition  environ¬ 
ments.  One  type  of  trade  study  is  used  for 
requirements  analysis.  During  this  analy¬ 
sis,  requirements  are  balanced  against 
each  other  or  against  specified  constraints, 
including  cost.  Requirements  analysis 
trade  studies  examine  and  analyze  alterna¬ 
tive  functional  and  performance  require¬ 
ments  to  present  system  options  to  satisfy 
customer  needs.  During  this  type  of 
analysis,  functions  are  balanced  with 
interface  and  established  equipment 
requirements,  configuration  considerations, 
functional  partitioning,  and  requirements 
“flow  down.” 

Trade  studies  are  conducted  during  design 
production  to  support  decisions  for  new 
product  and  process  developments  versus 
non-developmental  products  and  proc¬ 
esses.  They  are  used  to  evaluate  alterna¬ 
tive  solutions  to  optimize  cost,  schedule, 
performance,  and  risk. 

Trade  study  methods  are  used  during 
WARCON  engineering  concept  develop¬ 


Trade  Studies  are  a  formal  decision  mak¬ 
ing  methodology  used  by  integrated  teams 
to  make  choices,  provide  alternatives,  and 
resolve  conflicts  during  the  systems  engi¬ 
neering  process.  Good  trade  study  analy¬ 
ses  demand  participation,  collaboration, 
and  continuous  communications  between 
and  among  the  integrated  teams.  Without 
this  collaboration,  unwarranted  assump¬ 
tions  may  form  the  basis  for  a  solution  and 
could  result  in  omission  of  important  data. 
Trade  studies  identify  desirable  and  practi¬ 
cal  alternatives  among  technical  objectives, 
competing  designs,  program  schedules, 
and  functional  and  performance  require¬ 
ments.  Trade  Studies  also  identify  Total 
Ownership  Costs  and  enable  analysts  and 
acquisition  professionals  to  choose  among 
the  alternatives  using  pre-defined  criteria. 

Trade  studies  are  defined,  conducted,  and 
documented  in  enough  detail  to  support 
decision-making  and  lead  to  a  balanced 
system  solution.  The  level  of  detail  of  any 
trade  study  needs  to  be  commensurate 
with  cost,  schedule,  performance,  and  risk 
impacts. 
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Both  formal  and  informal  trade  studies  are 
conducted  in  any  systems  engineering 
activity.  Formal  trade  studies  tend  to  be 
those  that  will  be  used  in  formal  decision 
forums,  (e.g.,  milestone  decisions).  These 
typically  will  be  well  documented  and 
become  a  part  of  the  decision  database. 
Conversely,  engineering  choices  are  less 
formal,  involve  trade-offs  and  decisions 
that  parallel  the  trade  study  process,  and 
are  documented  in  summary  detail  only. 
These  summaries  are  important  in  that 
they  define  the  design  as  it  evolves. 

Trade  Study  Basics 

Trade  Studies  or  Trade-Off  Analyses  are 
processes  that  examine  viable  alternatives 
to  determine  the  preferred  option.  It  is 
important  that  there  be  criteria  established 
that  are  acceptable  to  all  members  of  the 
integrated  team  as  a  basis  for  a  decision. 
In  addition,  there  must  be  an  agreed  upon 
approach  to  measuring  alternatives  against 
the  criteria.  If  these  principles  are  followed, 
the  trade  study  should  produce  decisions 


that  are  rational,  objective,  supportable, 
and  repeatable. 

Trade  study  results  must  be  easily  com¬ 
municated  to  customers  and  decision 
makers.  If  results  of  a  trade  study  are  too 
complex  to  communicate  with  ease,  it  is 
unlikely  that  the  process  will  result  in  timely 
decisions. 

Trade  Study  Process 

As  shown  in  Figure  4,  the  process  of 
tradeoff  analysis  consists  of  defining  the 
problem,  establishing  a  trade-off  methodol¬ 
ogy  (to  include  the  establishment  of  deci¬ 
sion  criteria),  selecting  alternative  solu¬ 
tions,  determining  key  characteristics  of 
each  alternative,  evaluating  the  alterna¬ 
tives,  and  choosing  a  solution. 

The  first  steps  of  this  process  are  per¬ 
formed  during  the  "Analyze  Problem"  part 
of  the  WARCON  process  (Appendix  B; 
IDEFO  Node  A1)  where  the  Trade  Study 
Plan  was  developed. 


Source:  Systems  Engineering  Fundamentals,  Defense  Systems  Management  College  Press,  Fort  Belvoir,  VA,  1999 


Figure  4.  Trade  Study  Process 
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Total  Ownership  Cost  Analyses 

The  initial  stage  in  Develop  Trade  Study  is 
to  analyze  the  combined  cost  data  (Appen¬ 
dix  B;  IDEFO  Node  A6.1).  The  inputs 
necessary  include  the  System  Description, 
Alternative  Design  Concepts  and  their 
associated  costs,  and  cost  data  derived 
from  the  design  engineers  and  modeled  by 
the  systems  engineers.  The  analysts 
integrate  the  cost  data  with  the  system 
designs  and  develop  a  matrix  listing  sys¬ 
tems  and  costs. 

Acquisition  decisions  for  future  systems 
must  consider  more  than  just  the  cost  for 
developing  and  buying  the  system.  Al¬ 
though  acquisition  cost  often  drives  a  high- 
level  decision  about  whether  to  upgrade  or 
acquire  a  system,  decisions  regarding 
which  system  or  system  alternatives  to  buy 
must  include  TOC  over  the  lifetime  of  the 
system. 

TOC  has  three  major  components:  Acqui¬ 
sition,  Operating  and  Support  (O&S),  and 
Disposal.  Disposal  may  not  be  a  factor  in 
acquisition  of  small  electronics  systems, 
such  as  for  a  few  computers,  but  it  is  a 
major  factor  for  systems  containing  haz¬ 
ardous  materials  or  when  removing  a 
system  from  a  ship  would  require  major 
structural  changes. 

Operating  and  Support  are  the  recurring 
costs  that  are  required  for  maintaining  and 
using  the  system,  and  are  usually  budg¬ 
eted  annually.  Although  DoD  procurement 
often  focuses  on  acquisition,  organizations 
must  budget  for  the  legacy  O&S  costs 
throughout  the  system's  life  cycle.  Using 
TOC  rather  than  acquisition  cost  for  pro¬ 
curement  through  modeling  and  simulation 


and  Trade  Study  analysis  allows  the 
decision  maker  to  weigh  trade-offs  be¬ 
tween  systems  that  may  cost  more  initially, 
but  be  cheaper  to  operate  in  the  end. 

Three  major  categories  of  O&S  costs  are 
staffing,  maintenance,  and  sustaining 
support.  While  maintenance  and  sustain¬ 
ing  support  costs  are  best  addressed  as 
analysis  problems,  staffing  levels  can  be 
incorporated  into  M&S  systems,  and 
directly  analyzed  in  the  WARCON  process. 
Warfare  process  models  can  be  designed 
and  built  to  a  level  of  detail  that  allows 
workload  to  be  tracked  and  reported  out  as 
an  MOP. 

Some  Trade  Studies  may  also  describe 
these  categories  as  “Reliability,  Maintain¬ 
ability,  and  Availability”  (RMA)  when  refer¬ 
ring  to  life  cycle  or  total  ownership  cost. 
Regardless  of  the  term  of  art  chosen,  these 
costs  are  an  important  part  of  any  trade-off 
analysis. 

For  example,  the  current  Weapons  Han¬ 
dling  Process  for  an  aircraft  carrier  is 
manual  and  therefore  labor  intensive. 
System  improvements  that  include  automa¬ 
tion  of  key  process  steps  may  have  a 
significant  acquisition  cost,  but  may  show 
even  greater  savings  in  labor  throughout 
the  life  cycle  of  the  system. 

The  Engineering  Concept  Development 
phase  of  the  WARCON  process  (Appendix 
B;  IDEFO  Node  A3)  may  use  a  Trade  Study 
approach  at  the  engineering  level  for 
assessing  system  trade-offs  for  each 
alternate  design.  However,  the  cost  mod¬ 
els  available  for  this  phase  may  not  be 
available  to  address  all  aspects  of  TOC. 
The  first  step  in  performing  a  WARCON 
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Trade  Study  is  therefore  combining  cost 
data  from  the  alternative  design  data  set 
with  any  other  information  required  for 
TOC.  This  data  may  include,  for  example, 
labor  cost  data  from  the  Navy  for  individual 
billets  or  ranks.  This  data  can  be  used  to 
estimate  the  labor  cost  savings  achieved 
by  introducing  new  technology  into  system 
improvements. 

Performance  Data 

The  product  of  the  Conduct  Experiment 
phase  of  the  WARCON  process  (Appendix 
B;  IDEFO  Node  A5)  is  a  set  of  experiment 
data  for  the  baseline/  comparison  case  and 
each  excursion  case. 

This  information  includes: 

•  A  summary  of  input  data,  including 
scenario  data  and  performance  data 
for  the  engineering  concept  alterna¬ 
tive  being  tested 

•  Output  performance  data  as  values 
of  MOPs  and  MOEs 

Outputs  of  the  experiment,  from  the  Inte¬ 
grated  M&S  environment,  and  TOC  data 
combine  to  form  the  basis  of  Trade  Study 
Analyses. 

Trade  Study  Analysis 

The  final  step  in  the  WARCON  process  is 
to  perform  a  cost-performance  trade-off 
analysis  for  the  different  design  alternatives 
(Appendix  B;  IDEFO  Node  A6.2).  This  part 
of  the  process  is  shown  in  Figure  5.  The 
analysts  combine  the  TOC  data  matrix  with 
results  of  the  experiment  conducted  earlier 
(performance  data  in  the  form  of  MOPs 
and  MOEs)  for  the  alternative  designs. 


Each  experiment  excursion's  results  are 
tabulated  and  costs  compared.  The  ex¬ 
periment  results  are  listed  in  terms  of 
satisfaction  of  the  MOP/MOE  requirements 
and  to  what  degree  the  results  meet  the 
predetermined  requirements.  For  each 
excursion,  warfighter  requirements  are 
reviewed  once  more  to  ensure  that  opera¬ 
tional  requirements  match  up  with  each 
design  alternative  under  study. 

In  addition,  analysts  review  “Areas  of 
Interest”  (AOIs)  that  were  communicated 
by  the  customer  during  the  development  of 
the  Experiment  Plan.  These  Customer 
AOIs  are  an  important  element  of  the  final 
acquisition  recommendation  and  decision, 
since  the  customer  might  choose  Cost  as 
the  primary  consideration  for  one  of  the 
subsystems,  and  choose  Performance  as 
the  major  factor  in  selecting  yet  another 
component  of  the  system. 


Figure  5.  Trade  Study  Analysis 


Spider  Diagram  Tool  Set 

An  important  consideration  in  developing 
the  Trade  Study  is  identifying  a  visual 
means  of  displaying  trade-off  results.  To 
support  this  effort,  a  Spider  Graph  Visuali¬ 
zation  capability  has  been  developed. 
Spider  Diagrams  (also  sometimes  called 
radar  or  polar  plots)  are  useful  for  compar¬ 
ing  multiple  sets  of  data  that  contain  multi- 
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pie  variables.  Spider  Diagrams  provide  a 
simple  means  to  visualize  and  highlight  the 
differences  between  comparative  sets  of 
data.  This  format  is  ideal  for  displaying 
cost-performance  trade-offs  for  alternate 
system  designs. 

A  very  basic  Spider  Diagram  capability  is 
included  in  Microsoft®  Excel  as  a  function 
titled  Radar  Chart.  A  much  more  capable 
Spider  Diagram  Tool  Set  was  developed 
over  the  last  two  years  as  part  the  WAR- 
CON  effort.  The  Spider  Diagram  Tool  Set 
enables  the  user  to  organize  data  hierar¬ 
chically,  specify  data  sources  and  relation¬ 
ships,  and  then  interactively  explore  the 
resultant  information  displays.  Analysts 
can  start  at  a  top-level  diagram  and  drill 
down  into  the  underlying  data,  to  build  a 
better  understanding  of  the  information 
presented. 

An  example  of  a  spider  diagram  showing 
notional  WARCON  performance  results 
used  to  compare  alternative  systems 
designs  for  improvements  to  a  Carrier 
Weapons  Handling  System  is  shown  in 
Figure  6.  The  performance  measures  used 
for  the  analysis  were  Response  Time, 


Response  Time 


Workload  TOC 


Figure  6.  Example  of  WARCON  Spider  Diagram 
Results 


TOC,  and  Workload.  Therefore,  the  vari¬ 
ables  shown  on  the  spider  diagram  are 
Cost,  Response  Time,  and  Workload. 

For  this  notional  comparison  of  two  alterna¬ 
tive  system  options,  the  one  that  has  the 
highest  TOC  provides  dramatic  changes  in 
both  response  time  and  workload.  Sup¬ 
porting  documentation  would  show  details 
of  these  numbers  over  the  lifetime  of  the 
system.  The  Spider  Diagram  tool  provides 
a  visual  depiction  of  the  results  to  support 
analysis. 

Summary 

The  purpose  of  a  Trade  Study  is  to  make 
better  and  more  informed  decisions  in 
selecting  the  best  from  alternative  solu¬ 
tions.  Initial  trade  studies  focus  on  alterna¬ 
tive  system  concepts  and  requirements. 
Later  studies  assist  in  selecting  component 
part  designs.  Cost  effectiveness  analyses 
provide  assessments  of  alternative  solution 
performance  relative  to  cost. 

The  cost  effectiveness,  performance  trade¬ 
offs  and  proposed  recommendations  are 
then  formulated  into  the  Draft  Trade  Study 
(Appendix  B;  IDEFO  Node  A6.3).  This  data 
is  then  compared  to  the  Customer’s  Prob¬ 
lem  Statement  to  determine  if  the  analysis 
provides  a  solution  to  the  customer's 
problem. 

The  important  factor  to  consider  in  devel¬ 
opment  of  the  Trade  Study  once  the  TOC 
data  are  analyzed  is  the  relationship  to  the 
problem  the  process  was  invoked  to  con¬ 
sider.  The  customer  feedback  loop  (Ap¬ 
pendix  B;  IDEFO  Node  A6.4)  is  central  to 
completion  of  the  Trade  Study  and  the 
eventual  completion  of  the  WARCON 
process. 
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Finally,  a  Trade  Study  Report  is  prepared 
(Appendix  B;  IDEFO  Node  A6.5).  The 
Trade  Study  can  make  recommendations 
on  what  system  or  upgrades  to  acquire.  It 
can  also  make  a  recommendation  not  to 
acquire  anything,  but  rather  maintain  what 
is  already  in  place.  An  analysis  of  alterna¬ 


tive  designs  may  reveal  that  current  tech¬ 
nologies  are  insufficient  to  meet  the  re¬ 
quirements  specified  by  the  customer.  In 
other  words,  it  is  perfectly  acceptable  to 
make  a  negative  recommendation  in  the 
Trade  Study. 
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Chapter  7  —  Collaborative  Engineering  Enterprise 


The  WARCON  process  is  designed  to 
bring  together  representatives  from  gov¬ 
ernment  and  industry  to  study  a  system 
procurement  or  change  issue.  Members  of 
a  WARCON  team  often  are  geographically 
dispersed  and  the  efforts  of  the  individual 
Groups  (i.e.,  Analysis,  Engineering  Con¬ 
cept  Design  and  Systems  Engineers), 
although  dedicated  to  a  common  goal,  are 
wide-ranging.  Accordingly,  a  tool  is 
needed  by  which  the  Program  Manager 
can  manage  details  of  the  project  in  a 
virtual  environment,  and  allow  for  collabo¬ 
ration  among  the  different  groups.  The 
WARCON  process  uses  a  Collaborative 
Engineering  Enterprise  (CEE)  to  accom¬ 
plish  this  task. 

The  strategy  for  CEE  development  is  to 
establish  a  collaboration  framework  in  step 
with  existing  and  emerging  domain-specific 
resources  to  support  scientific  and  engi¬ 
neering  collaboration  between  distributed 
government  and  industry  teams.  When 
two  or  more  enterprises  form  a  team  to 
design  and  build  a  complex  system,  one  of 
the  first  tasks  that  must  be  performed  is  the 
exchange  of  information  required  for  design, 
specification  generation,  document  review, 
and  system  performance  evaluation. 

Complex  projects  are  usually  executed  by 
multi-skilled  teams,  whose  members  are 
often  made  up  of  personnel  from  both 
inside  and  outside  of  the  organization. 


Coordinating  a  complex  project  across  the 
country  or  even  around  the  globe  is  com¬ 
mon.  The  CEE  is  a  system  that  electroni¬ 
cally  links  government  and  industry  part¬ 
ners  who  are  members  of  a  multi-tiered 
enterprise.  Going  far  beyond  a  simple 
integrated  email  and  web  system,  a  CEE 
can  be  used  to  distribute  and  manage 
documentation  and  data  associated  with  a 
large  scale  enterprise,  serve  as  an  on-line 
meeting  place  for  team  collaboration  and 
tasking  support  as  well  as  providing  com¬ 
mon  tools  and  management  support 
capabilities. 

CEE  Architecture  and 
Development  Approach 

The  CEE  employs  a  client-server  para¬ 
digm.  Users  can  access  the  CEE  through 
the  Internet  or  a  classified  network.  The 
CEE  architecture  includes  the  layers 
shown  in  Figure  7.  The  system  is  intended 
to  run  on  a  range  of  hardware  from  desktop 
computers  to  hand  held  wireless  personal 
digital  assistants  (PDAs).  The  repository  is 
implemented  with  distributed  databases  so 
the  system  will  scale  to  serve  a  large 
number  of  users  simultaneously. 

Defense  applications  require  unique  com¬ 
mon  tools.  In  addition,  some  tools  required 
by  a  particular  program  must  be  included. 
The  architecture  is  designed  to  fit  the 
purpose. 
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Figure  7.  CEE  Reference  Architecture 


To  support  the  operation  of  these  pro¬ 
grams,  some  of  the  desired  CEE  functions 
include  the  following: 

•  Application  integration  and  man¬ 
agement  —  Embed  internal  and  exter¬ 
nal  user  applications  (e.g.  simulations, 
analysis  tools,  etc.)  capable  of  auto¬ 
matically  launching  and  setting  the 
collaboration  if  needed 

•  Authentication  —  Confirms  the  iden¬ 
tity  of  system  users  or  agents 

•  Context  factory  “  Maintains  context- 
specific  information,  e.g.  shared  cal¬ 
endars  and  files,  thereby  allowing 
consistent  and  separable  data  to  be 
accessed  by  the  user 

•  Database  and  query  engine  ~ 

Transports  enterprise  information  into 
the  database  for  the  collaborative  en¬ 


terprise.  In  addition,  the  engine  can 
acquire  appropriate  information  from 
external  databases. 

•  Meeting  session  management  ~ 

Establish  meeting  sessions  and  broker 
messages  directed  to  the  meetings 

•  Notification  ~  Accept  and  route  mes¬ 
sages  between  participants,  deter¬ 
mine  the  status  of  the  user  (on  or  off 
line)  and  direct  appropriate  notification 

•  Presence  factory  ~  Generate  and 
deliver  a  personalized  interface  to  re¬ 
mote  users,  and  store  configuration 
information  such  as  shortcuts  and 
preferences  for  later  use 

•  Transformation  ”  Translate  docu¬ 
ments,  data  and  multi-media  files  from 
one  format  to  another,  such  as  Rich 
Text  Format  (RTF)  to  simple  text 
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•  Transportation  —  Distribute  docu¬ 
ments,  data  and  multi-media  files 
through  the  entire  domain  of  the  col¬ 
laborative  enterprise,  regardless  of 
where  it  is  stored 

•  Unified  workspace  —  Incorporate  a 
seamless  management  of  shared 
data  resources  throughout.  Compo¬ 
nents  and  agents  can  interact,  com¬ 
municate,  and  collaborate. 

•  Summations  and  Action  Items  ~ 

Produce  a  summary  with  action  items 
for  teleconferences  and  meetings. 
These  notes  should  be  available  for 
review  and  comment  on  Groove™,  a 
commercial  collaborative  software 
“workspace”  being  used  by  WARCON 
IPTs,  or  other  appropriate  collabora¬ 
tive  enterprise  software  that  may  be 
available  in  the  future. 

Graphic  User  Interface 
Considerations 

It  is  important  to  understand  that  the  CEE 
user  interface  must  support  the  different 
needs  required  by  each  of  its  users.  Three 
different  views  are  needed  to  accomplish 
this: 

•  General  information  display  and 
navigation 

•  Self-oriented  view 

•  Team/task-oriented  view. 

The  general  information  display  should 
facilitate  the  data  and  document  navigation 
and  retrieval.  The  characteristics  for  the 
self-oriented  view  are  self-project  and  self¬ 
activities  management.  The  team/task- 
oriented  view  characteristics  are  informa¬ 
tion  sharing  among  or  across  the  team 


members  to  collaborate  both  concurrently 
and  non-concurrently. 

It  is  helpful  to  think  of  a  collaborative 
working  environment  as  a  series  of  build¬ 
ings,  each  with  floors  and  rooms.  The 
building  represents  the  project  whereas  the 
floors  and  rooms  might  represent  shared 
responsibilities  and  tasks  within  the  group. 
This  paradigm  represents  virtual  space 
within  which  applications,  documents,  and 
people  are  directly  accessible. 

Commercial  Off-The-Shelf  tools  and  appli¬ 
cations,  designed  for  team  operation  can 
be  embedded  in  the  CEE.  With  certain 
programs,  members  initializing  these  tools, 
will  automatically  set  up  a  meeting  session 
and  link  the  users  together  without  the 
need  for  a  lengthy  manual  procedure.  As  a 
new  tool  is  developed  for  the  enterprise,  it 
can  be  embedded  here  for  the  teams  to 
use. 

The  CEE  provides  the  basis  for  document 
sharing  and  distributed  operations  for 
conducting  analysis  and  study.  Users  can 
place  documents  of  different  types  into  the 
CEE,  allowing  anyone  else  with  access  to 
read  the  document.  Persistence  is  sup¬ 
ported  because  the  document  exists  even 
though  no  one  is  logged  onto  the  CEE. 
Consequently,  the  document  remains  in 
the  CEE  for  future  visitors  to  see  until  it  is 
moved  or  deleted  by  an  authorized  user. 

The  CEE  must  provide  the  ability  to  restrict 
access,  based  on  an  access  control  list. 
Specific  individuals  may  be  added  or 
removed  from  the  access  control  list  as 
necessary.  This  is  especially  important  for 
protecting  the  proprietary  information  from 
different  companies  participating  in  a  joint 
venture.  This  will  reduce  the  reluctance  for 
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making  sensitive  information  available 
within  a  shared,  but  access-controlled 
environment. 

Process  Flow 

Major  challenges  to  overcome  in  the 
WARCON  process  are  communicating  and 
working  together  through  the  distributed 
nature  of  the  program.  For  this  reason,  the 
CEE  should  incorporate  a  Process  Flow 
capability  to  aid  team  operations.  This  will 
enable  IPTs  to  collaborate,  define,  and 
develop  the  process  for  a  given  task 
associated  with  the  WARCON  process. 
More  importantly,  it  fosters  communication 
within  the  team  to  minimize  misunderstand¬ 
ings  regarding  responsibilities  and  roles  for 
each  team  member.  The  Process  Flow  is 
used  as  a  vehicle  for  team  members  to 
submit  their  completed  works.  The  work 
completed  by  one  member  will  be  auto¬ 
matically  uploaded  and  saved  in  the  CEE 
servers  after  their  submission  into  the 
system  and  a  copy  is  automatically  routed 
to  the  next  responsible  member(s).  The 
major  advantage  of  the  Process  Flow  is  its 
ability  to  function  as  the  "glue"  for  different 
IPT  teams. 


Analysis  and  Visualization  Tool 

A  primary  goal  of  using  the  WARCON 
process  goal  is  to  provide  readily  under¬ 
stood  information  that  reflects  the  tradeoffs 
and  impact  of  various  system  designs.  The 
means  to  understanding  the  tradeoffs 
involved  in  this  process  can  be  provided  by 
analysis  and  visualization  tools  incorpo¬ 
rated  in  the  CEE.  Spider  Graph  (see 
Figure  7)  visualization  is  one  example  of  a 
tool  developed  to  do  this  task.  The  Spider 
Graph  application  is  integrated  into  the 
CEE  so  it  can  be  used  as  shared  resource 
for  the  team. 

Summary 

Hardware,  software,  telecommunication, 
and  network  technology  advances  enable 
creation  of  the  virtual  enterprise;  however, 
technology  by  itself  does  not  ensure  the 
success  of  the  virtual  enterprise.  Rather,  it 
is  an  enabler.  The  CEE  will  provide  capa¬ 
bilities  to  enhance  the  IPT  team  operations. 
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Appendix  A  —  ACRONYMS 


AARS . After  Action  Review  System 

CEE . Collaborative  Engineering  Environment 

CIE . Concept  Investigation  Environment 

CONOPS . Concept  of  Operations 

COTS . Commercial  off  the  Shelf 

CWHS . Carrier  Weapons  Handling  System 

DMSO . Defense  Modeling  and  Simulation  Office 

DoD . Department  of  Defense 

DPG . Defense  Planning  Guidance 

GOTS . Government  off  the  Shelf 

HLD . High  Level  Design 

IDEFO . Integration  Definition  for  Function  Modeling 

IPT . Integrated  Process  Team 

KA/E . Knowledge  Acquisition/Engineering 

LAN . Local  Area  Network 

M&S . Modeling  and  Simulation 

MOE . Measure  of  Effectiveness 

MOP . Measure  of  Performance 

NMSD . National  Military  Strategy  Document 

O&S . Operations  and  Support 

ONR . Office  of  Naval  Research 

PDA . Personal  Digital  Assistant 

PM . Project  Manager 

PMP . Project  Management  Plan 

POA&M . Plan  of  Action  and  Milestones 

POE . Projected  Operational  Environment 

R&D . Research  and  Development 

RMA . Reliability,  Maintenance,  and  Availability 

RTF . Rich  Text  Format 

SDREN . Secret  Defense  Research  and  Engineering  Network 

SIPRNET . Secret  Internet  Protocol  Router  Network 

SME . Subject  Matter  Expert 

SRD . Systems  Requirement  Document 

SSS . System  Subsystem  Specification 

TOC . Total  Ownership  Cost 

V&V . Verification  and  Validation 

VPN . Virtual  Private  Network 

WAN . . Wide  Area  Network 

WARCON . Warfighting  Concepts  to  Future  Weapon  System  Designs 

WBS . Work  Breakdown  Structure 


MTS  Technologies,  Inc. 


42 


For  Official  Use  Only 


Appendix  B  —  Integration  Definition  for  Function  Modeling 
(IDEF0)  format _ 


Diagrams  and  Definitions 
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AO  -  WARCON  Integration  Definition  for  Function  Modeling  (IDEFO) 

A  process  using  Warfighter  Concepts,  coupled  with  operations  analysis  linked  to  modeling 
and  simulation,  to  increase  long-term  effectiveness,  improve  acquisition  cycle  time,  and 
reduce  total  ownership  costs  of  new  weapons  systems  (Figure  AA-0). 
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Figure  A-A-0  WARCON  IDEFO 


Inputs 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 

Warfighter  Concepts  -  Requirements  for  future  weapon  system  designs  that  may 
include  ORDs,  MNS,  ROCs,  OAG  inputs,  etc. 
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Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Resource  Costs  -  External  financial  resource  data  required  to  support  the  WARCON 
process  regarding  equipping,  sustaining,  and  operating  military  forces  sufficient  to 
meet  national  goals. 

Controls 

Formal  DoD  Requirements  and  Policies  -  Formal  requirements  documents  and 
policy  instructions  related  to  the  acquisition  process  and  future  weapons  systems 
requirements. 

Technology  Availability/Capability -The  technologies  currently  available  to  improve 
the  weapon  system  or  process  being  studied  and  an  initial  appraisal  of  the  available 
technologies. 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Modeling  and  Simulation  (M&S)  Availabiiity/Capability-  Identification  and 
assessment  of  the  models  and  simulations  available  to  support  the  analysis,  and  their 
capabilities,  for  potential  inclusion  into  the  integrated  system/federation. 

Subject  System  Data  Availability- Access  to  data  concerning  Operational 
Capabilities,  Availability,  Maintainability  and  Reliability  of  the  weapon  system  (and 
associated  systems)  to  be  studied. 

Outputs 

Trade  Study  Report  -  The  primary  product  resulting  from  the  WARCON  process  to 
support  acquisition  decision  makers.  This  formal  report  summarizes  costperformance 
trade-offs  among  the  different  options  for  future  weapon  system  designs. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A1  Perform  Project  Planning 

Identifying  all  functions  and  resources  required  to  support  implementation  of  the 
WARCON  process  based  on  the  customer  problem  statement  (Figure  A-AO(a)). 


Figure  A-AO(a)  Execute  WARCON  Process 
Inputs: 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 

Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 
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Outputs: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A1.1  Tailor  WARCON  Process 


Customizing  the  generic  WARCON  process  for  analyzing  the  subject  systems  identified  in 
customer  problem  statement  using  the  Recommended  Practices  Guide  (RPG)  and 
problem  definition  (Figure  A-AI(a)). 


Recommended  Practices  Guide 


Tools  Project  Management  Tools 


Figure  AA1(a)  Perform  Project  Planning 


Inputs: 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 
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Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 

Tailored  Process  -  Customized  IDEFO  diagrams  and  definitions  developed  for  each 
specific  customer  problem  statement  for  applying  the  WARCON  process. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A1.1.1  Define  Problem 

Analyzing  the  Customer’s  Problem  Statement  and  determining  the  problem  domain,  the 
context  in  which  the  problem  occurs,  the  scope  of  the  system  that  will  be  studied  and 
identify  necessary  planning  assumptions  (Figure  A-AI.I(a)). 


Personnel 


Figure  A-AI.I(a)  Tailor  WARCON  Process 


Inputs: 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 
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Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Problem  Definition  -  The  customer  problem  statement  providing  sufficient  detail  to 
support  program  planning,  process  tailoring,  and  determining  the  procedures  the 
experiment  will  use  to  study  the  customer’s  issues. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A1.1.2  Determine  Analysis  Approach 

Determining  the  analytic  framework  and  methods  to  be  used  to  evaluate  and  compare 
alternate  solutions  to  support  the  customer’s  acquisition  decision  (Figure  A1.1(b)) 
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Figure  AA1.1(b)  Tailor  WARCON  Process 


Inputs: 

Problem  Definition  -  The  customer  problem  statement  providing  sufficient  detail  to 
support  program  planning,  process  tailoring,  and  determining  the  procedures  the 
experiment  will  use  to  study  the  customer’s  issues. 
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Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A1.1.3  Determine  Engineering  Design  Approach 


Identify  the  genera!  approach  to  be  used  in  developing  the  engineering  concepts  for 
subject  system  improvement  alternatives  (Figure  A1 .1(c)). 


Figure  AA1.1(c)  Tailor  WARCON  Process 


Inputs: 

Problem  Definition  -  The  customer  problem  statement  providing  sufficient  detail  to 
support  program  planning,  process  tailoring,  and  determining  the  procedures  the 
experiment  will  use  to  study  the  customer’s  issues. 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 
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Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Engineering  Design  Approach  -  Description  of  the  design  for  the  federation 
architecture  and  models  needed  for  simulation  and  evaluation. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A1.1.4  Determine  Systems  Engineering  Architecture 

Define  the  Integrated  modeling  and  simulation  environment  required  to  support  execution 
of  the  experiment  (Figure  A-AI.I(d)). 


Figure  AA1.1(d)  Tailor  WARCON  Process 


Inputs: 

Problem  Definition  -  The  customer  problem  statement  providing  sufficient  detail  to 
support  program  planning,  process  tailoring,  and  determining  the  procedures  the 
experiment  will  use  to  study  the  customer’s  issues. 

Engineering  Design  Approach  -  Description  of  the  design  for  the  federation 
architecture  and  models  needed  for  simulation  and  evaluation. 
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Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

System  Architecture  -  The  integrated  modeling  and  simulation  environment  required 
to  support  execution  of  the  experiment. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A1.1.5  Tailor  WARCON  IDEFO 

Refine  and  customize  the  generic  WARCON  process  to  best  fit  the  Analysis  Approach  and 
System  Engineering  Architecture  for  the  specific  customer  problem  being  addressed  using 
the  WARCON  Recommended  Practices  Guide  (Figure  A-A1(e)). 


Personnel 


Figure  AA1.1(e)  Tailor  WARCON  Process 


Inputs: 

System  Architecture  -  The  integrated  modeling  and  simulation  environment  required 
to  support  execution  of  the  experiment. 

Engineering  Design  Approach  -  Description  of  the  design  for  the  federation 
architecture  and  models  needed  for  simulation  and  evaluation. 
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Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 

Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Tailored  Process  -  Customized  IDEFO  diagrams  and  definitions  developed  for  each 
specific  customer  problem  statement  for  applying  the  WARCON  process. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A1.2  Plan  WARCON  Execution 

Defining  and  developing  the  tasks,  products,  organization,  schedules  and  resources 
necessary  to  successfully  implement  the  WARCON  process  for  a  specific  program  (Figure 
A-AI(b)). 


Recommended  Practices  Guide 


Tools  Project  Management  Tools 


Figure  AA1(b)  Perform  Project  Planning 


Inputs: 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 

Tailored  Process  -  Customized  IDEFO  diagrams  and  definitions  developed  for  each 
specific  customer  problem  statement  for  applying  the  WARCON  process. 
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Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Project  Execution  Plan  -The  detailed  plan  for  products,  tasks,  schedules, 
organization,  and  resources  necessary  to  complete  the  experiment  and  analysis  that 
investigates  the  customer’s  problem  statement. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A1.2.1  Develop  List  of  Products 

Defining  a  list  of  products  needed  to  support  and  document  the  tailored  WARCON 
process  for  a  specific  customer  problem  using  the  RPG  (Figure  AA1.2(a)). 
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Figure  A-A1.2(a)  Plan  WARCON  Execution 


Inputs: 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 

Tailored  Process  -  Customized  IDEFO  diagrams  and  definitions  developed  for  each 
specific  customer  problem  statement  for  applying  the  WARCON  process. 
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Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

WARCON  Product  List  -  List  of  products  required  to  support  and  document  the 
tailored  WARCON  process  for  a  specific  customer  problem. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A1.2.2  Develop  List  of  Project  Tasks 

Performing  a  work  breakdown  structure  (WBS)  and  determining  the  tasks  required  to 
complete  the  WARCON  process  for  a  specific  customer  problem  statement  using  the  list 
of  products  and  tailored  WARCON  process  (Figure  A-A1 .2(b)). 
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Figure  A-A1.2(b)  Plan  WARCON  Execution _ 

Inputs: 

WARCON  Product  List  -  List  of  products  required  to  support  and  document  the 
tailored  WARCON  process  for  a  specific  customer  problem. 

Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 
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Outputs: 

Project  Tasks  -  A  single  element  of  the  WBS  required  for  employing  the  WARCON 
process. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A1.2.3  Develop  Project  POA&M 

Producing  a  schedule  and  milestones  for  task  execution  using  the  WBS  (Figure  A- 
A1.2(c)). 
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Figure  A-A1.2(c)  Plan  WARCON  Execution 
Inputs: 

Project  Tasks- A  single  element  of  the  WBS  required  for  employing  the  WARCON 
process. 

Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 
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Outputs: 

Project  POA&M  -  Plan  of  Action  and  Milestones  for  executing  the  WARCON  process 
for  a  specific  customer  problem. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A1.2.4  Define  Project  Organization 

Determining  the  program  organizational  structure  that  will  best  support  completing  tasks, 
supporting  product  development,  and  achieving  program  goals  for  a  specific  customer 
problem  (Figure  A-A1.2(d)). 
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Figure  A-A1.2(d)  Plan  WARCON  Execution 


Inputs: 

Project  POA&M  -  Plan  of  Action  and  Milestones  for  executing  the  WARCON  process 
for  a  specific  customer  problem. 

Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 
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Outputs: 

Project  Organization  -  Organizational  structure  designed  to  meet  requirements  for 
executing  the  WARCON  process  for  a  specific  customer  problem. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A1.2.5  Define  Project  Resources 

Identifying  resources  required  to  execute  the  WARCON  process  for  a  specific  customer 
problem  (Figure  A-A1.2(e)). 


Inputs: 

Project  Organization  -  Organizational  structure  designed  to  meet  requirements  for 
executing  the  WARCON  process  for  a  specific  customer  problem. 

Project  POA&M  -  Plan  of  Action  and  Milestones  for  executing  the  WARCON  process 
for  a  specific  customer  problem. 

Project  Tasks- A  single  element  of  the  WBS  required  for  employing  the  WARCON 
process. 
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WARCON  Product  List  -  List  of  products  required  to  support  and  document  the 
tailored  WARCON  process  for  a  specific  customer  problem. 

Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Project  Execution  Plan  -  The  detailed  plan  for  products,  tasks,  schedules, 
organization,  and  resources  necessary  to  complete  the  experiment  and  analysis  that 
investigates  the  customer’s  problem  statement. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A1.3  Define  Project  Costs 

Determining  the  modeling  and  simulation,  hardware,  software,  personnel,  analysis  tools, 
and  other  costs  required  to  complete  the  WARCON  process  for  a  specific  customer 
problem  using  the  Project  Execution  Plan  (Figure  AA1(c)). 
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Figure  A-A1.2(c)  Plan  WARCON  Execution 


Inputs: 

Project  Execution  Plan  -The  detailed  plan  for  products,  tasks,  schedules, 
organization,  and  resources  necessary  to  complete  the  experiment  and  analysis  that 
investigates  the  customer’s  problem  statement. 
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Resource  Costs  -  External  financial  resource  data  required  to  support  the  WARCON 
process  regarding  equipping,  sustaining,  and  operating  military  forces  sufficient  to 
meet  national  goals. 

Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Project  Costs  -  The  final  dollar  figure  submitted  to  the  customer  to  complete  the 
investigation. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the  modeling 
and  analysis  environments. 
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A1.4  Develop  Project  Management  Plan 

Combining  the  contract  costs  and  the  Execution  Plan  to  provide  guidance  for  executing  all 
phases  of  the  WARCON  process  (Figure  A-AI(d)). 


Recommended  Practices  Guide 


Tools  Project  Management  Tools 


Figure  AA1.2(d)  Plan  WARCON  Execution 


Inputs: 

Project  Costs  -  The  final  dollar  figure  submitted  to  the  customer  to  complete  the 
investigation. 

Project  Execution  Plan  -The  detailed  plan  for  products,  tasks,  schedules, 
organization,  and  resources  necessary  to  complete  the  experiment  and  analysis  that 
investigates  the  customer’s  problem  statement. 
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Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 

Tailored  Process  -  Customized  IDEFO  diagrams  and  definitions  developed  for  each 
specific  customer  problem  statement  for  applying  the  WARCON  process. 

Controls: 

Recommended  Practices  Guide  -  A  WARCON  Publication  provided  to  users  for  use 
in  tailoring  and  implementing  the  WARCON  process  for  a  specific  customer  problem. 

Outputs: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2  Analyze  Problem 

Detailing  examination  of  the  customer  requirements  using  current  capabilities  and  future 
resources  (Figure  A-AO(b)). 


Figure  A-AO(b)  Execute  WARCON  Process 


Inputs: 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 
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Warfighter  Concepts  -  Requirements  for  future  weapon  system  designs  that  may 
include  ORDs,  MNS,  ROCs,  OAG  inputs,  etc. 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Alternative  Concept  Designs  -  Potential  design  innovations  that  may  resolve  or 
reduce  the  capabilities  gap. 

Controls: 

Formal  DoD  Requirements  and  Policies  -  Formal  requirements  documents  and 
policy  instructions  related  to  the  acquisition  process  and  future  weapons  systems 
requirements. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

High  Level  Design  (HLD)  -  Plan  for  building  the  Integrated  System;  requires  program 
review  approval. 

Outputs: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.1  Define  Problem  in  Detail 

Performing  a  detailed  analysis  of  the  Problem  Definition  in  an  operational  context  to 
restate  the  problem  in  terms  amenable  to  defining  scope,  assumptions  and  limitations, 
and  detailed  analysis  approach  (Figure  A-A2(a)). 


Tools  (Analysis  Tools ) 


Figure  A-A2(a)  Analyze  Problem 


Inputs: 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 

Warfighter  Concepts  -  Requirements  for  future  weapon  system  designs  that  may 
include  ORDs,  MNS,  ROCs,  OAG  inputs,  etc. 
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Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 


Controls: 

Formal  DoD  Requirements  and  Policies  -  Formal  requirements  documents  and 
policy  instructions  related  to  the  acquisition  process  and  future  weapons  systems 
requirements. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Detailed  Problem  Definition  -  A  detailed  description  of  the  customer  problem  in 
analytic  terms  including  the  scope  of  the  problem,  assumptions  and  limitations,  and 
analysis  approach. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.1.1  Define  Problem  in  Analytic  Terms 

Analyzing  the  customer  problem  statement  with  sufficient  thoroughness  to  devise 
modeling,  simulation,  analysis  and  trade  study  requirements  (Figure  A-A2.1(a)). 


Personnel 

(Analysts) 


Figure  AA2.1(a)  Define  Problem  in  Detail 


Inputs: 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 

Problem  Definition  and  Analysis  Approach  -  An  expansion  of  the  customer 
problem  statement  providing  sufficient  detail  to  support  program  planning,  process 
tailoring,  and  determining  the  procedures  the  experiment  and  analysis  will  use  to  study 
the  customer’s  issues. 
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Warfighter  Concepts  -  Requirements  for  future  weapon  system  designs  that  may 
include  ORDs,  MNS,  ROCs,  OAG  inputs,  etc. 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Controls: 

Formal  DoD  Requirements  and  Policies  -  Formal  requirements  documents  and 
policy  instructions  related  to  the  acquisition  process  and  future  weapons  systems 
requirements. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Detailed  Problem  Definition  -  A  detailed  description  of  the  customer  problem  in 
analytic  terms  including  the  scope  of  the  problem,  assumptions  and  limitations,  and 
analysis  approach. 

Experiment  Hypotheses  -  Description  of  the  hypotheses  that  will  be  tested  during  the 
experiment. 

Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.1.2  Identify  Assumptions  and  Limitation 

Identifying  operational,  analytical  and  system  engineering  assumptions  and  limitations  that 
will  constrain  how  the  analysis  is  performed  and  provide  a  context  for  interpreting 
experiment  results  (Figure  ArA2.1(b)). 


Customer  Formal  DoD  Requirements  &  Policies 

Problem 


Personnel 

(Analysts) 


Figure  AA2.1(b)  Define  Problem  in  Detail 


Inputs: 

Detailed  Problem  Definition  -  A  detailed  description  of  the  customer  problem  in 
analytic  terms  including  the  scope  of  the  problem,  assumptions  and  limitations,  and 
analysis  approach. 
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Controls: 

Formal  DoD  Requirements  and  Policies  -  Formal  requirements  documents  and 
policy  instructions  related  to  the  acquisition  process  and  future  weapons  systems 
requirements. 

Outputs: 

Assumptions  and  Limitations  -  Description  of  the  assumptions  and  limitations  for 
the  analysis  and  experiment. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.1.3  Determine  Detailed  Approach  and  Methodology 

Defining  the  Analysis  Approach  in  sufficient  detail  to  allow  the  detailed  functional 
requirements  for  the  Integrated  M&S  System  to  be  defined  to  address  all  aspects  of  the 
customer  problem  (Figure  AA2.1(c)). 


Personnel 

(Analysts) 


Figure  AA2.1(c)  Define  Problem  in  Detail 


Inputs: 

Assumptions  and  Limitations  -  Description  of  the  assumptions  and  limitations  for 
the  analysis  and  experiment. 

Detailed  Problem  Definition  -  A  detailed  description  of  the  customer  problem  in 
analytic  terms  including  the  scope  of  the  problem,  assumptions  and  limitations,  and 
analysis  approach. 


MTS  Technologies,  Inc. 


84 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 

Controls: 

Formal  DoD  Requirements  and  Policies  -  Formal  requirements  documents  and 
policy  instructions  related  to  the  acquisition  process  and  future  weapons  systems 
requirements. 

Outputs: 

Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.1.4  Define  Hypotheses 

Defining  the  specific  experimental  hypotheses  to  be  tested  during  the  experiment  using 
the  Integrated  M&S  System  (Figure  A-A2.1(d)). 


Formal  DoD  Requirements  &  Policies 


Personnel 

(Analysts) 


Figure  A-A2.1(d)  Define  Problem  in  Detail 


Inputs: 

Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Assumptions  and  Limitations  -  Description  of  the  assumptions  and  limitations  for 
the  analysis  and  experiment. 

Detailed  Problem  Definition  -  A  detailed  description  of  the  customer  problem  in 
analytic  terms  including  the  scope  of  the  problem,  assumptions  and  limitations,  and 
analysis  approach. 
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Controls: 

Formal  DoD  Requirements  and  Policies  -  Formal  requirements  documents  and 
policy  instructions  related  to  the  acquisition  process  and  future  weapons  systems 
requirements. 

Outputs: 

Experiment  Hypotheses  -  Description  of  the  hypotheses  that  will  be  tested  during  the 
experiment. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.2  Define  M&S  System  Functional  Requirements 

Determining  the  unconstrained  modeling  and  simulation  requirements  for  completely 
assessing  all  aspects  of  the  customer  problem  statement  (Figure  A-A2.2(b)). 


Figure  A-A2(b)  Analyze  Problem 


Inputs: 

Detailed  Problem  Definition  -  A  detailed  description  of  the  customer  problem  in 
analytic  terms  including  the  scope  of  the  problem,  assumptions  and  limitations,  and 
analysis  approach. 

Detailed  Analysis  Approach- Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 


MTS  Technologies,  Inc. 


88 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Controls: 

Experiment  Hypotheses  -  Description  of  the  hypotheses  that  will  be  tested  during  the 
experiment. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.3  Formulate  Draft  Experiment  and  Trade  Study  Plans 

Comparing  the  unconstrained  functional  requirements  to  the  available  M&S  capabilities  to 
determine  the  parts  of  the  customer  problem  can  be  addressed,  using  analysis  and 
available  M&S,  within  program  resource  constraints  (Figure  A-A2(c)). 


Problem  Definition 


Formal  DoD  Requirements  &  Policies 


Tools  (Analysis  Tools ) 


Figure  AA2(c)  Analyze  Problem 


Inputs: 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 
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Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Alternative  Concept  Descriptions  -  Potential  innovations  that  may  resolve  or 
decrease  the  capability  gap. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

High  Level  Design  (HLD)  -  Plan  for  building  the  Integrated  System;  requires  program 
review  approval. 

Outputs: 

Draft  Experiment  Plan  -  Draft  document  that  defines  the  experiment  approach, 
objectives,  hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs), 
analysis  methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Draft  Trade  Study  Plan  -  Draft  document  that  defines  the  approach,  methods,  and 
performance  measures  to  be  used  to  assess  trade-offs  among  alternate  weapon 
system  designs  and  total  ownership  costs. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.3.1  Review  Constraints  on  Functional  Requirements 

Taking  the  unconstrained  functional  requirements  for  the  M&S  System  and  imposing 
constraints  based  on  the  High  Level  Design  and  Project  Management  Plan  (Figure  A- 
A2.3(a)). 


Tools) 


Figure  AA2.3(a)  Formulate  Draft  Experiment  and  Trade  Study  Plans 


Inputs: 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 
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Alternative  Concept  Descriptions  -  Potential  innovations  that  may  resolve  or 
decrease  the  capability  gap. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Constrained  Functional  Requirements  -  List  of  constrained  M&S  system  functional 
requirements. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.3.2  Design  Experiment 

Designing  an  experiment  that  can  be  realistically  performed  within  the  resource 
constraints  of  the  project  using  the  selected  M&S  capabilities  and  the  detailed  analysis 
approach  (Figure  A-A2.3(b)). 


Tools) 


Figure  ArA2.3(b)  Formulate  Draft  Experiment  and  Trade  Study  Plans 


Inputs: 

Constrained  Functional  Requirements  -  List  of  constrained  M&S  system  functional 
requirements. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 
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Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Alternative  Concept  Descriptions  -  Potential  innovations  that  may  resolve  or 
decrease  the  capability  gap. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Draft  Experiment  Plan  -  Draft  document  that  defines  the  experiment  approach, 
objectives,  hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs), 
analysis  methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 


MTS  Technologies,  Inc. 


95 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


A2.3.2.1  Identify  Baseline/Comparison  Case 

Identifying  the  experiment  case  that  will  use  as  a  baseline  for  comparing  results  of  each 
excursion.  The  baseline/comparison  case  may  be  based  on  a  current  warfare  system  or 
operational  concept  that  the  customer  problem  statement  seeks  to  improve  or  on  a 
previously  defined  system  solution  (Figure  A-A2.3.2(a)). 


Problem  Project  Management  Plan 


Figure  A-A2.3.2(a)  Design  Experiment 
Inputs: 

Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 
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Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

Alternative  Concept  Descriptions  -  Potential  innovations  that  may  resolve  or 
decrease  the  capability  gap. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Description  of  Baseline/Comparison  Case  -  Description  of  the  baseline  or 
comparison  experiment  case  used  to  compare  excursion  results,  based  on  minimum 
subject  system  requirements. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.3.2.2  Identify  Excursion  Cases 

Developing  variations  to  the  Baseline/Comparison  Case,  based  on  potential 
improvements  to  the  minimum  subject  system  requirements,  to  be  modeled  and  analyzed 
using  experiment  data  (Figure  A-A2.3.2(b)). 


Problem  Project  Management  Plan 


Tools) 


Figure  AA2.3.2(b)  Design  Experiment 


Inputs: 

Description  of  Baseline/Comparison  Case  -  Description  of  the  baseline  or 
comparison  experiment  case  used  to  compare  excursion  results,  based  on  minimum 
subject  system  requirements. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 
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Alternative  Concept  Descriptions  -  Potential  innovations  that  may  resolve  or 
decrease  the  capability  gap. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Description  of  Excursion  Cases  -  Description  of  Excursion  Cases  to  be  used  during 
the  experiment  execution  in  sufficient  detail  to  allow  quantitative  performance 
measures  to  be  defined. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.3.2.3  Define  MOPs  and  MOEs 

Identifying  and  defining  quantitative  measures  that  can  be  used  to  characterize 
operational  performance  and  effectiveness  for  the  subject  system  excursions  being 
modeled  (Figure  A-A2.3.2(c)). 


Figure  A-A2. 3.2(c)  Design  Experiment 


inputs: 

Description  of  Excursion  Cases  -  Description  of  Excursion  Cases  to  be  used  during 
the  experiment  execution  in  sufficient  detail  to  allow  quantitative  performance 
measures  to  be  defined. 
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Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Constrained  Functional  Requirements  -  List  of  constrained  M&S  system  functional 
requirements. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Outputs: 

MOPs  and  MOEs  -  Description  of  quantitative  Measures  of  Performance  and 
Measures  of  Effectiveness  to  be  used  for  the  experiment  and  Trade  Study. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.3.2.4  Identify  Data  Extraction  Requirements 

Determining  the  data  required  from  the  Integrated  M&S  System  during  experiment 
execution  to  support  MOP  and  MOE  evaluation  for  the  Baseline/Comparison  and 
Excursion  Cases  (Figure  A- A2. 3. 2(d)). 


Problem  Project  Management  Plan 


Tools) 


Figure  AA2. 3.2(d)  Design  Experiment 


Inputs: 

MOPs  and  MOEs  -  Description  of  quantitative  Measures  of  Performance  and 
Measures  of  Effectiveness  to  be  used  for  the  experiment  and  Trade  Study. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 
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Outputs: 

Data  Extraction  Requirements  -  List  of  data  extraction  requirements  for  the 
Integrated  M&S  System  during  experiment  execution. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.3.2.5  Determine  Data  Analysis  Methods 

Identifying  the  analysis  methods  and  tools  to  be  used  in  analyzing  experiment  data 
(Figure  A-A2.3.2(e)). 


Project  Management  Plan 


Tools  (Analysis 
Tools) 


Figure  AA2.3.2(e)  Design  Experiment 


inputs: 

Data  Extraction  Requirements  -  List  of  data  extraction  requirements  for  the 
Integrated  M&S  System  during  experiment  execution. 

MOPs  and  MOEs  -  Description  of  quantitative  Measures  of  Performance  and 
Measures  of  Effectiveness  to  be  used  for  the  experiment  and  Trade  Study. 

Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 
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Constrained  Functional  Requirements-  List  of  constrained  M&S  system  functional 
requirements. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Draft  Experiment  Plan  -  Draft  document  that  defines  the  experiment  approach, 
objectives,  hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs), 
analysis  methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.3.3  Design  Trade  Study 

Determining  the  approach,  methods,  and  performance  measures  to  be  used  to  assess 
trade-offs  among  alternate  weapon  system  designs  and  total  ownership  costs,  based  on 
experiment  data  for  operational  performance  and  cost,  and  integrating  any  required 
external  cost-performance  data  (Figure  A-A2.3(c)). 


Tools  (Analysis 
Tools) 


Figure  AA2.3(c)  Formulate  Draft  Experiment  and  Trade  Study  Plans 


Inputs: 

Draft  Experiment  Plan  -  Draft  document  that  defines  the  experiment  approach, 
objectives,  hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs), 
analysis  methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 
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Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

TOC  Data  -  External  financial  resource  data  required  to  support  the  WARCON 
process  regarding  equipping,  sustaining,  and  operating  military  forces  sufficient  to 
meet  national  goals. 

Alternative  Concept  Descriptions  -  Potential  innovations  that  may  resolve  or 
decrease  the  capability  gap. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Draft  Trade  Study  Plan  -  Draft  document  that  defines  the  approach,  methods,  and 
performance  measures  to  be  used  to  assess  trade-offs  among  alternate  weapon 
system  designs  and  total  ownership  costs. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.3.3.1  Define  Trade  Study  Analysis  Framework 

Determining  the  detailed  approach  to  be  used  to  evaluate  trade-offs  between  operational 
performance  and  total  ownership  cost  for  improved  subject  system  alternatives  based  on 
experiment  data  (Figure  A-2. 3.3(a)). 


Project  Management  Plan 


i  oois  i  Ana  lysis 
Tools) 


Figure  AA2. 3.3(a)  Design  Trade  Study 


Inputs: 

Draft  Experiment  Plan  -  Draft  document  that  defines  the  experiment  approach, 
objectives,  hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs), 
analysis  methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 
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Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Alternative  Concept  Descriptions  -  Potential  innovations  that  may  resolve  or 
decrease  the  capability  gap. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Trade  Study  Analysis  Framework  -  Description  of  the  detailed  approach  to  be  used 
to  evaluate  trade-offs  between  operational  performance  and  total  ownership  cost  for 
improved  subject  system  alternatives  based  on  experiment  data. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.3.3.2  Identify  Trade  Study  Data  Requirements 

Determining  the  types  and  sources  of  data  required  to  perform  the  Trade  Study,  based  on 
experiment  data,  and  including  any  required  external  data  (Figure  A-A2.3.3(b)). 
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Figure  A-A2.3.3(b)  Design  Trade  Study 


Inputs: 

Trade  Study  Analysis  Framework  -  Description  of  the  detailed  approach  to  be  used 
to  evaluate  trade-offs  between  operational  performance  and  total  ownership  cost  for 
improved  subject  system  alternatives  based  on  experiment  data. 

Alternative  Concept  Descriptions  -  Potential  innovations  that  may  resolve  or 
decrease  the  capability  gap. 
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Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

TOC  Data  -  External  financial  resource  data  required  to  support  the  WARCON 
process  regarding  equipping,  sustaining,  and  operating  military  forces  sufficient  to 
meet  national  goals. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Outputs: 

Trade  Study  Data  Requirements  -  Description  of  all  data  required  to  perform  the 
Trade  Study. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.3.3.3  Determine  Trade  Study  Analysis  Melhods 

Determining  the  detailed  analysis  methods  and  tools  required  to  perform  the  detailed 
trade-off  analysis  of  alternate  subject  system  designs  and  solutions  (Figure  A-A2.3.3(c)). 


Project  Management  Plan 


Figure  ArA2.3.3(c)  Design  trade  Study 


inputs: 

Trade  Study  Data  Requirements  -  Description  of  all  data  required  to  perform  the 
Trade  Study. 

Trade  Study  Analysis  Framework  -  Description  of  the  detailed  approach  to  be  used 
to  evaluate  trade-offs  between  operational  performance  and  total  ownership  cost  for 
improved  subject  system  alternatives  based  on  experiment  data. 
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Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Outputs: 

Trade  Study  Analysis  Methods-  Description  of  the  analysis  methods  and  tools 
required  to  perform  the  detailed  trade-off  analysis  of  alternate  subject  system  designs 
and  solutions. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.3.3.4  Develop  Trade  Study  Tools 

Assessing  available  methods  and  tools  for  performing  Trade  Study  analysis,  adapting  and 
tailoring  the  available  tools  as  required,  and  developing  any  new  tools  not  already 
available  (Figure  A-A2.3.3(d)). 


Project  Management  Plan 


Tools) 


Figure  AA2.3.3(d)  Design  Trade  Study 


Inputs: 

Trade  Study  Analysis  Methods  -  Description  of  the  analysis  methods  and  tools 
required  to  perform  the  detailed  trade-off  analysis  of  alternate  subject  system  designs 
and  solutions. 

Trade  Study  Data  Requirements  -  Description  of  all  data  required  to  perform  the 
Trade  Study. 
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Trade  Study  Analysis  Framework  -  Description  of  the  detailed  approach  to  be  used 
to  evaluate  trade-offs  between  operational  performance  and  total  ownership  cost  for 
improved  subject  system  alternatives  based  on  experiment  data. 

Controls: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Outputs: 

Draft  Trade  Study  Plan  -  Draft  document  that  defines  the  approach,  methods,  and 
performance  measures  to  be  used  to  assess  trade-offs  among  alternate  weapon 
system  designs  and  total  ownership  costs. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A2.4  Perform  Customer  Review 

Providing  the  customer  with  draft  Experiment  and  Trade  Study  Plans  for  review  and 
meeting  to  discuss  customer  comments  and  recommendations  (Figure  A-A2(d)). 


Problem  Definition 


Formal  DoD  Requirements  &  Policies 


Tools  (Analysis  Tools ) 


Figure  AA2(d)  Analyze  Problem 


Inputs: 

Draft  Experiment  Plan  -  Draft  document  that  defines  the  experiment  approach, 
objectives,  hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs), 
analysis  methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 
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Draft  Trade  Study  Plan  -  Draft  document  that  defines  the  approach,  methods,  and 
performance  measures  to  be  used  to  assess  trade-offs  among  alternate  weapon 
system  designs  and  total  ownership  costs. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Customer  Review  Comments  -  Comments  received  from  the  customer  during  the 
review  process. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A2.5  Prepare  Experiment  and  Trade  Study  Plans 

Incorporating  customer  comments  into  the  draft  plans  (Figure  A-A2(e)). 


Problem  Definition  Formal  DoD  Requirements  &  Policies 


Figure  AA2(e)  Analyze  Problem 


Inputs: 

Customer  Review  Comments  -  Comments  received  from  the  customer  during  the 
review  process. 

Draft  Experiment  Plan  -  Draft  document  that  defines  the  experiment  approach, 
objectives,  hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs), 
analysis  methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 
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Draft  Trade  Study  Plan  -  Draft  document  that  defines  the  approach,  methods,  and 
performance  measures  to  be  used  to  assess  trade-offs  among  alternate  weapon 
system  designs  and  total  ownership  costs. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

TOC  Data  -  External  financial  resource  data  required  to  support  the  WARCON 
process  regarding  equipping,  sustaining,  and  operating  military  forces  sufficient  to 
meet  national  goals. 

Detailed  Analysis  Approach  -  Description,  in  detail,  of  the  analysis  approach  that  will 
support  definition  of  functional  requirements  and  Experiment/Trade  Study  design. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A3  Develop  Engineering  Concepts 

Develops  concepts  in  physical  terms,  and  provides  cost  estimates  for  them,  that  may  be 
modeled,  and  simulated.  The  physical  characteristics  of  the  alternative  Concept  System(s) 
are  determined.  The  concepts  developed  are  the  potential  physical  solutions  to  the 
operational  problem  set  forth  by  prior  analysis  (Figure  A-AO(c)). 


Figure  A-AO(c)  Execute  WARCON  Process 


Input: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  Measures  of  Performance  and  Effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 
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Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  and  operational  scenarios. 

Warfighter  Concepts  -  Requirements  for  future  weapon  system  designs  that  may 
include  ORDs,  MNS,  ROCs,  OAG  inputs,  etc. 

Industry  DoD  Technical  Data  -  Relevant  information  for  design  gathered  from 
industry  and  DoD  sources  about  new  and  otherwise  applicable  technologies  that  may 
be  used  to  determine  a  concept  system. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Alternate  Concepts  Descriptions  -  Tabulates  the  conglomeration  of  technologies 
selected  to  be  part  of  the  concept  system  with  a  general  vision  of  their  eventual 
arrangement  with  one  another. 

Engineering  Data  for  Alternative  Designs  -  Concept  System  data  collated  in  the 
form  of  a  Concept  Engineering  Package  providing  a  Concept  Schematic,  any  Software 
Design  Documents  that  may  be  applicable,  Material  Lists,  a  Short  System  Description, 
a  Concept  System  Specification,  and  a  likelihood  estimate  for  the  Concept  System’s 
prospects  of  actually  being  developed. 

Cost  Data  for  Alternative  Designs  -  Rough  order  of  magnitude  estimates  of 
acquisition  costs  in  relative  terms,  as  well  as  estimates  of  total  ownership  costs  of  the 
subject  Concept  Systems  under  study. 

Mechanisms: 

Personnel  -  Engineers,  Analysts,  Subject  Matter  Experts,  and  other  government  and 
contracted  employees  having  cognizance  in  the  activity. 

Tools- Accepted  methods  and  engineering  resources  that  support  the  activity. 

Facility  -  Building  and  equipment  necessary  to  support  the  personnel  and  tools 
involved  in  the  activity. 
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A3.1  Determine  Capabilities  Gap 

Identifies  the  difference  between  existing  and  desired  operational  states,  and  reduces 
these  differences  into  engineering  terms  for  design  (Figure  A-A3(a)). 


' — ' 

Facility 


Figure  A-A3(a)  Develop  Engineering  Concepts 


Input: 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Warfighter  Operations  Data  -  The  representation  of  facts,  information,  or 
instructions,  formalized  to  be  suitable  for  communication,  of  warfighter  operations  as 
experienced  in  the  field. 

Warfighter  Concepts  -  Requirements  for  future  weapon  system  designs  that  may 
include  ORDs,  MNS,  ROCs,  OAG  inputs,  etc. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  and  operational  scenarios. 
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Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Baseline  Substance  Field  (Su-Field)  Diagrams  -  Schematics  depicting  Subject  - 
Action  -  Object  relationships  between  component  objects  in  the  baseline  system  under 
study. 

Functional  Limits,  Bottlenecks,  and  Extrapolations-  A  report  describing  the 
functional  capability  limitations  to  the  existing  baseline  system.  These  limits  are 
presented  as  system  conflicts,  i.e.  bottlenecks  that  prohibit  the  system  from  achieving 
greater  capability.  Extrapolations  beyond  these  limits  that  show  what  greater  capability 
can  be  achieved  if  the  limits  were  to  be  overcome  are  also  included  in  the  report. 

Engineering  Process  Map  -  A  flowchart  detailing  on  an  engineering  level  the 
activities  and  events  involved  with  the  operation  under  study.  The  map  is  developed 
by  Subject  Matter  Experts  having  intimate  experience  with  and  immediate  knowledge 
of,  the  operation  being  studied. 

Engineering  Functional  Requirements  Specifications  -  Delineates  on  the 
engineering  level  the  functional  capabilities  for  engineering  to  address  in  subsequent 
development  of  the  Concept  Systems. 

Gap  Analysis  Report  -  A  description  of  the  gap  measures  determined.  The  report 
may  include  descriptions  of  the  system  conflicts  causing  a  gap,  and  the  functional 
system  requirements  aimed  at  closing  a  gap. 

Engineering  Functional  Requirements  Data  -  Requirements  extracted  from  the 
Engineering  Functional  Requirements  Specification  and  put  onto  a  Requirements 
Management  Application  database  for  subsequent  tracking  and  analysis. 

Mechanisms: 

Personnel  -  Engineers,  Analysts,  Subject  Matter  Experts,  and  other  government  and 
contracted  employees  having  cognizance  in  the  activity. 

Tools- Accepted  methods  and  engineering  resources  that  support  the  activity. 

Faculty  -  Building  and  equipment  necessary  to  support  the  personnel  and  tools 
involved  in  the  activity. 
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A3.1.1  Establish  Baseline  Functional  Limits  and  Excursions 

Determines  limitations  to  the  existing  baseline  system.  Limits  are  presented  as  system 
conflicts,  i.e.  bottlenecks  that  prohibit  the  system  from  achieving  greater  capability. 
Excursions  are  extrapolated  beyond  these  limits  to  see  what  greater  capability  can  be 
achieved  if  the  limits  were  to  be  overcome  (Figure  A-A3.1(a)). 


Figure  A-A3.1(a)  Determine  Capabilities  Gap 


Inputs: 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  and  operational  scenarios. 
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Warfighter  Operations  Data  -  The  representation  of  facts,  information,  or 
instructions,  formalized  to  be  suitable  for  communication,  of  warfighter  operations  as 
experienced  in  the  field. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Baseline  Su-Field  Diagrams  -  Schematics  depicting  Subject  -  Action  -  Object 
relationships  between  component  objects  in  the  baseline  system  under  study. 

Functional  Limits,  Bottlenecks,  and  Extrapolations-  A  report  describing  the 
functional  capability  limitations  to  the  existing  baseline  system.  These  limits  are 
presented  as  system  conflicts,  i.e.  bottlenecks  that  prohibit  the  system  from  achieving 
greater  capability.  Extrapolations  beyond  these  limits  that  show  what  greater  capability 
can  be  achieved  if  the  limits  were  to  be  overcome  are  also  included  in  the  report. 

Engineering  Process  Map  -  A  flowchart  detailing  on  an  engineering  level  the 
activities  and  events  involved  with  the  operation  under  study.  The  map  is  developed 
by  Subject  Matter  Experts  having  intimate  experience  with  and  immediate  knowledge 
of  the  operation  being  studied. 

Engineering  Baseline  Requirements  Data  -  Requirements  extracted  from  the 
Engineering  Process  Maps,  and  Su-Field  Diagrams  and  put  onto  a  Requirements 
Management  Application  database  with  the  requirements  data  from  prior  engineering 
activities  for  subsequent  tracking  and  analysis. 

Mechanisms: 

Personnel  -  Subject  Matter  Experts,  Analysts,  Engineers  and  other  government  and 
contracted  employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods,  and  engineering  resources  that  support  the  activity. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility-  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A3.1.2  Define  Ideal  System  Capabilities 

Determines  the  actual  functional  capabilities  desired  for  engineering  to  address  from 
considerations  of  the  problem  posed,  the  limits  and  bottlenecks  (Figure  A-A3.1(b)). 


Figure  A-A3.1(b)  Determine  Capabilities  Gap 


Inputs: 

Functional  Limits,  Bottlenecks,  and  Extrapolations-  A  report  describing  the 
functional  capability  limitations  to  the  existing  baseline  system.  These  limits  are 
presented  as  system  conflicts,  i.e.  bottlenecks  that  prohibit  the  system  from  achieving 
greater  capability.  Extrapolations  beyond  these  limits  that  show  what  greater  capability 
can  be  achieved  if  the  limits  were  to  be  overcome  are  also  included  in  the  report. 
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Engineering  Baseline  Requirements  Data  -  Requirements  extracted  from  the 
Engineering  Process  Maps,  and  Su-Field  Diagrams  and  put  onto  a  Requirements 
Management  Application  database  with  the  requirements  data  from  prior  engineering 
activities  for  subsequent  tracking  and  analysis. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  and  operational  scenarios. 

Warfighter  Concepts  -  Requirements  for  future  weapon  system  designs  that  may 
include  ORDs,  MNS,  ROCs,  OAG  inputs,  etc. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Desired  Functional  Capabilities  -  A  report  delineating  the  functional  capabilities  desired  for 
engineering  to  address. 

Engineering  Ideal  Requirements  Data  -  Requirements  extracted  from  the  Desired 
Functional  Capabilities,  and  put  onto  a  Requirements  Management  Application 
database  with  other  requirements  data  for  subsequent  tracking  and  analysis. 

Mechanisms: 

Personnel  -  Analysts,  Subject  Matter  Experts,  Engineers  and  other  government  and 
contracted  employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility-  Buildings  and  Equipment  that  are  necessary  to  support  personnel  and  tools 
in  the  conduct  of  the  activities. 
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A3.1.3  Quantify  Engineering  Capabilities  Gaps 

Expresses  capabilities  of  the  existing  baseline  system,  and  the  capabilities  desired  in 
terms  of  measures  (Figure  A  A3. 1(c)) 


Figure  AA3.1(c)  Determine  Capabilities  Gap 


Inputs: 

Desired  Functional  Capabilities  -  A  report  delineating  the  actual  functional 
capabilities  desired  for  engineering  to  address. 

Functional  Limits,  Bottlenecks,  and  Extrapolations-  A  report  describing  the 
functional  capability  limitations  to  the  existing  baseline  system.  These  limits  are 
presented  as  system  conflicts,  i.e.  bottlenecks  that  prohibit  the  system  from  achieving 
greater  capability.  Extrapolated  beyond  these  limits  that  show  what  greater  capability 
can  be  achieved  if  the  limits  were  to  be  overcome  are  also  included  in  the  report. 
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Engineering  idea!  Requirements  Data  -  Requirements  extracted  from  the  Desired 
Functional  Capabilities,  and  put  onto  a  Requirements  Management  Application 
database  with  other  requirements  data  for  subsequent  tracking  and  analysis. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Gap  Measures  -  A  listing  of  measures  that  express  the  differences  between  the 
capabilities  of  the  existing  baseline  system,  and  the  capabilities  desired. 

Engineering  Gap  Requirements  Data  -  Requirements  extracted  from  the  Gap 
Measures,  and  put  onto  a  Requirements  Management  Application  database  with  other 
requirements  data  for  subsequent  tracking  and  analysis. 

Mechanisms: 

Personnel  -  Analysts,  Subject  Matter  Experts,  Engineers  and  other  government  and 
contracted  employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Buildings  and  Equipment  that  are  necessary  to  support  personnel  and  tools 
in  the  conduct  of  the  activities. 
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A3.1.4  Define  Engineering  Functional  Requirements 

Reduces  the  gap  measures  to  essential  functional  requirements  for  engineering.  Those 
functional  requirements  that  are  in  conformance  with  the  problem  definition,  scenario,  and 
greater  operational  functional  requirements  are  to  be  considered  essential.  Requirements 
are  transitioned  from  the  language  of  the  warfighter  to  the  language  understood  by 
engineers  (Figure  A-A3.1(d)). 


Facility 


Figure  AA3.1(d)  Determine  Capabilities  Gap 


Inputs: 

Gap  Measures  -  A  list  of  measures  that  express  the  differences  between  the 
capabilities  of  the  existing  baseline  system,  and  the  capabilities  desired. 

Engineering  Gap  Requirements  Data  -  Requirements  extracted  from  the  Gap 
Measures,  and  put  onto  a  Requirements  Management  Application  database  with  other 
requirements  data  for  subsequent  tracking  and  analysis. 
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Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  and  operational  scenarios. 

Desired  Functional  Capabilities  -  A  report  developed  delineating  the  actual 
functional  capabilities  desired  for  engineering  to  address. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Engineering  Functional  Requirements  Specifications  -  Delineates  on  the 
engineering  level  the  functional  capabilities  for  engineering  to  address  in  subsequent 
development  of  the  Concept  Systems. 

Engineering  Functional  Requirements  Data  -  Requirements  extracted  from  the 
Engineering  Functional  Requirements  Specifications,  and  put  onto  a  Requirements 
Management  Application  database  with  other  requirements  data  for  subsequent 
tracking  and  analysis. 

Gap  Analysis  Report  -  A  description  of  the  gap  measures  determined.  The  report 
may  include  descriptions  of  the  system  conflicts  causing  a  gap,  and  the  functional 
system  requirements  aimed  at  closing  a  gap. 

Mechanisms: 

Personnel  -  Analysts,  Subject  Matter  Experts,  Engineers  and  other  government  and 
contracted  employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Buildings  and  Equipment  that  are  necessary  to  support  personnel  and 
tools  in  the  conduct  of  the  activities. 
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A3.2  Identify  Potential  Innovation  Concepts 

Finds  technology  solutions  to  reduce  or  eliminate  the  identified  capability  gaps  (Figure  A 
A3(b)). 


Facility 


Figure  AA3(b)  Develop  Engineering  Concepts 


Input: 

Functional  Limits,  Bottlenecks,  and  Extrapolations-  A  report  describing  the 
functional  capability  limitations  to  the  existing  baseline  system.  These  limits  are 
presented  as  system  conflicts,  i.e.  bottlenecks  that  prohibit  the  system  from  achieving 
greater  capability.  Extrapolated  beyond  these  limits  that  show  what  greater  capability 
can  be  achieved  if  the  limits  were  to  be  overcome  are  also  included  in  the  report. 
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Baseline  Su-Field  Diagrams  -  Schematics  depicting  Subject  -  Action  -  Object 
relationships  between  component  objects  in  the  baseline  system  under  study. 

Industry  DoD  Technical  Data  -  Relevant  information  for  design  gathered  from 
industry  and  DoD  sources  about  new  and  otherwise  applicable  technologies  that  may 
be  used  to  determine  a  concept  system. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Candidate  Technology  List  -  Tabulation  of  technologies  that  appear  candidate  for 
inclusion  into  a  physical  system  design.  The  tabulation  would  include  key 
characteristics  for  consideration  of  each  technology  listed. 

Mechanisms: 

Personnel  -  Subject  Matter  Experts,  Engineers,  and  other  government  and  contracted 
employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A3.2.1  Search  Industry  and  DoD  Technology  Databases 

Finds  technologies  that  pose  to  resolve  the  performance  gaps  between  the  existing 
baseline  and  with  what  is  desired  (Figure  A-A3.2(a)). 


Facility 


Figure  AA3.2(a)  Identify  Potential  Innovation  Concepts 


Inputs: 

Baseline  Su-Field  Diagrams  -  Schematics  depicting  Subject  -  Action  -  Object 
relationships  between  component  objects  in  the  baseline  system  under  study. 

Functional  Limits,  Bottlenecks,  and  Extrapolations-  A  report  describing  the 
functional  capability  limitations  to  the  existing  baseline  system.  These  limits  are 
presented  as  system  conflicts,  i.e.  bottlenecks  that  prohibit  the  system  from  achieving 
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greater  capability.  Extrapolated  beyond  these  limits  that  show  what  greater  capability 
can  be  achieved  if  the  limits  were  to  be  overcome  are  also  included  in  the  report. 

Industry  DoD  Technical  Data  -  Relevant  information  for  design  gathered  from 
industry  and  DoD  sources  about  new  and  otherwise  applicable  technologies  that  may 
be  used  to  determine  a  concept  system. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Technology  Descriptions  -  Short  Synopsis  of  subject  technologies  found  from 
searches  of  Industry  and  DoD  sources. 

Mechanisms: 

Personnel  -  Subject  Matter  Experts,  Engineers  and  other  government  and  contracted 
employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Search  Agents  -  Autonomous  software  modules  decoupled  from  regular  software 
applications  with  a  level  of  intelligence  able  to  accomplish  the  goal  of  finding  new 
technology  solutions  from  existing  Industry  and  DoD  databases. 

TRIZ  Methods  -  Regular  means  developed  or  otherwise  descendent  from  the 
Theory  of  Inventive  Problem  Solving  as  originally  described  by  Dr.  Altshuller. 

R&D  Roadmap  -  Databases  inherent  to  the  particular  project  that  warehouse  data 
on  new  emerging  or  otherwise  applicable  technologies  for  future  considerations. 

Facility  -  That  necessary  to  support  personnel  and  tools  in  the  conduct  of  the 
activities. 
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A3.2.2  Establish  Technology  Maturity,  Feasibility,  and  Relevance 

Applies  ratings  of  maturity,  feasibility,  and  relevance  to  subject  technologies  for  the 
purpose  of  eventually  establishing  a  likelihood  probability  of  the  technologies  actual  future 
existence  ultimately  for  an  estimate  of  a  future  concept’s  risk  (Figure  AA3.2(b)). 


Facility 


Figure  A-A3.2(b)  Identify  Potential  Innovation  Concepts 


Inputs: 

Technology  Descriptions  -  Short  Synopsis  of  subject  technologies  found  from 
searches  of  Industry  and  DoD  sources. 
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Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Technology  Prospects  -  Probability  of  the  technology’s  actual  future  existence 
determined  from  estimates  of  technology  maturity,  feasibility,  and  relevance. 

Mechanisms: 

Personnel  -  Engineers  and  other  government  and  contracted  employees  having 
cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

R&D  Roadmap  -  Databases  inherent  to  the  particular  project  that  warehouse  data 
on  new  emerging  or  otherwise  applicable  technologies  for  future  considerations. 

Facility  -  That  necessary  to  support  personnel  and  tools  in  the  conduct  of  the 
activities. 
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A3.2.3  Categorize  Technologies 

Brings  technologies  found  in  searches  of  industry  and  DoD  sources  into  the  classification 
systems  pertinent  to  the  particular  project  (Figure  A-A3.2(c)). 


Facility 


Figure  A-A3.2(c)  Identify  Potential  Innovation  Concepts 


Inputs: 

Technology  Descriptions  -  Short  Synopsis  of  subject  technologies  found  from 
searches  of  Industry  and  DoD  sources. 

Technology  Prospects  -  Probability  of  the  technology’s  actual  future  existence 
determined  from  estimates  of  technology  maturity,  feasibility,  and  relevance. 
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Controls: 

Project  Management  Plan -The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Candidate  Technology  List  -  Tabulation  of  technologies  that  appear  candidate  for 
inclusion  into  a  physical  system  design.  The  tabulation  would  include  key 
characteristics  for  consideration  of  each  technology  listed. 

Mechanisms: 

Personnel  -  Engineers  and  other  government  and  contracted  employees  having 
cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

R&D  Roadmap  -  Databases  inherent  to  the  particular  project  that  warehouse  data 
on  new  emerging  or  otherwise  applicable  technologies  for  future  considerations. 

Facility  -  That  necessary  to  support  personnel  and  tools  in  the  conduct  of  the  activities. 


MTS  Technologies,  Inc. 


139 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


A3.3  Select  Alternative  Engineering  Concepts 

Correlates  engineering  requirements  stating  the  problem  to  technology  solutions  that  pose 
as  solutions  to  the  problem,  and  then  architects  cohesive  engineering  concepts 
embodying  those  technologies  actually  selected  (Figure  A-A3(c)). 


Facility 


Figure  AA3(c)  Develop  Engineering  Concepts 


Input: 

Engineering  Functional  Requirements  Specifications  -  Delineates  on  the 
engineering  level  the  functional  capabilities  for  engineering  to  address  in  subsequent 
development  of  the  Concept  Systems. 

Gap  Analysis  Report  -  A  description  of  the  gap  measures  determined.  The  report 
may  include  descriptions  of  the  system  conflicts  causing  a  gap,  and  the  functional 
system  requirements  aimed  at  closing  a  gap. 

Candidate  Technology  List  -  Tabulation  of  technologies  that  appear  candidate  for 
inclusion  into  a  physical  system  design.  The  tabulation  would  include  key 
characteristics  for  consideration  of  each  technology  listed. 

Engineering  Functional  Requirements  Data  -  Requirements  extracted  from  the 
Engineering  Functional  Requirements  Specifications,  and  put  onto  a  Requirements 
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Management  Application  database  with  other  requirements  data  for  subsequent 
tracking  and  analysis. 

Engineering  Process  Map  -  A  flowchart  detailing  on  an  engineering  level  the  activities 
and  events  involved  with  the  operation  under  study.  The  map  is  developed  by  SMEs 
having  intimate  experience  with  and  immediate  knowledge  of  the  operation  being  studied. 

Concept  System  Conflicts  -  System  characteristics  working  against  one  another 
causing  limitations  in  the  concept  system  that  prohibits  the  system  from  realizing  the 
full  functionality  desired.  This  provides  iterative  feedback  to  designated  prior  activities. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Alternative  Concept  Descriptions  -  Tabulates  the  conglomeration  of  technologies 
selected  to  be  part  of  the  concept  system  with  a  general  vision  of  their  eventual 
arrangement  with  one  another. 

Initial  Concept  Schematics  -  Initial  generalized  diagrams  depicting  the  Concept 
Systems  to  be  further  developed. 

Engineering  Concepts  Requirements  Data  -  Requirements  extracted  from  the  Initial 
Concept  Diagrams,  the  Descriptions,  The  final  Su-field  Diagrams,  and  Engineering 
Process  Maps;  and  put  onto  a  Requirements  Management  Application  database  with 
other  requirements  data  for  subsequent  tracking  and  analysis. 

Final  Engineering  Process  Map  -  The  baseline  Process  Map  modified  to  reflect  the 
new  functionality  allowed  by  the  alternative  Concept  Systems  identified. 

Final  Su-Field  Diagrams  -  The  baseline  Su-field  Diagrams  modified  to  reflect  the  new 
functionality  allowed  by  the  selected  technologies  for  the  concept  system  to  be  developed. 

Mechanisms: 

Personnel  -Subject  Matter  Experts,  Engineers,  and  other  government  and  contracted 
employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Facility  -  That  necessary  to  support  personnel  and  tools  in  the  conduct  of  the  activities. 
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A3.3.1  Correlate  Technologies  to  Requirements 

Technologies  are  matched  to  the  functional  requirements  they  may  satisfy  (Figure  A 
A3. 3(a)). 


Facility 


Figure  AA3.3(a)  Select  Alternative  Engineering  Concepts 


Inputs: 

Engineering  Functional  Requirements  Data  -  Requirements  extracted  from  the 
Engineering  Functional  Requirements  Specifications,  and  put  onto  a  Requirements 
Management  Application  database  with  other  requirements  data  for  subsequent 
tracking  and  analysis. 
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Candidate  Technology  List  -  Tabulation  of  technologies  that  appear  candidate  for 
inclusion  into  a  physical  system  design.  The  tabulation  would  include  key 
characteristics  for  consideration  of  each  technology  listed. 

Engineering  Functional  Requirements  Specifications  -  Delineates  on  the 
engineering  level  the  functional  capabilities  for  engineering  to  address  in  subsequent 
development  of  the  Concept  Systems. 

Gap  Analysis  Report  -  A  description  of  the  gap  measures  determined.  The  report 
may  include  descriptions  of  the  system  conflicts  causing  a  gap,  and  the  functional 
system  requirements  aimed  at  closing  a  gap. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Technologies  to  Requirements  Matrix  (Concept  Box)- A  matrix  relating 
technologies  to  respective  functional  requirements  that  are  satisfied  by  the  technology. 
This  document  is  colloquially  known  as  the  “Concept  Box”. 

Engineering  Correlation  Requirements  Data  -  Requirements  extracted  from  the 
Concept  Box,  and  put  onto  a  Requirements  Management  Application  database  with 
other  requirements  data  for  subsequent  tracking  and  analysis. 

Mechanisms: 

Personnel  -  Engineers  and  other  government  and  contracted  employees  having 
cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A3.3.2  Select  Alternative  Technologies 

Down  selects  technologies  in  the  Technologies  to  Requirements  Matrix  that  best  satisfy 
the  functional  requirements  set  forth  (Figure  A- A3. 3(b)). 


Facility 


Figure  AA3.3(b)  Select  Alternative  Engineering  Concepts 


Inputs: 

Technologies  to  Requirements  Matrix  -  The  matrix  relating  technologies  to 
functional  requirements  that  are  satisfied  by  a  respective  technology. 

Engineering  Correlation  Requirements  Data  -  Requirements  extracted  from  the 
Concept  Box,  and  put  onto  a  Requirements  Management  Application  database  with 
other  requirements  data  for  subsequent  tracking  and  analysis. 

Baseline  Su-Field  Diagrams  -  Schematics  depicting  Subject  -  Action  -  Object 
relationships  between  component  objects  in  the  baseline  system  under  study. 
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Concept  System  Conflicts  -  System  characteristics  working  against  one  another 
causing  limitations  in  the  concept  system  that  prohibits  the  system  from  realizing  the 
full  functionality  desired.  This  provides  iterative  feedback  to  designated  prior  activities. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Alternative  Concept  Description  -  Tabulates  the  conglomeration  of  technologies 
selected  to  be  part  of  the  concept  system  with  a  general  vision  of  their  eventual 
arrangement  with  one  another. 

Modified  Su-Field  Diagrams  -  The  baseline  Su-field  Diagrams  modified  to  reflect  the 
new  functionality  allowed  by  the  selected  technologies  for  the  concept  system  to  be 
developed. 

Engineering  Technologies  Requirements  Data  -  Requirements  extracted  from  the 
Alternative  Concept  Descriptions,  Modified  Su-field  Diagrams,  and  put  onto  a 
Requirements  Management  Application  database  with  other  prior  requirements  data 
for  subsequent  tracking  and  analysis. 

Mechanisms: 

Personnel  -  Engineers,  Subject  Matter  Experts,  and  other  government  and  contracted 
employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

TRIZ  Methods  -  Regular  means  developed  or  otherwise  descendent  from  the 
Theory  of  Inventive  Problem  Solving  as  originally  described  by  Dr.  Altshuller. 

Axiomatic  Design  Methods  -  Regular  means  based  on  a  systematic  set  of  rules 
for  the  synthesis  of  concept  designs. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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I 


A3.3.3  Develop  Integrated  Concept  Technologies 

Takes  the  conglomeration  of  selected  technologies  and  integrates  then  into  a  cohesive 
idea;  establishes  the  Concept  System  (Figure  A-A3.3(c)). 


Figure  A-A3.3(c)  Select  Alternative  Engineering  Concepts 


Inputs: 

Alternative  Concept  Descriptions -Tabulates  the  conglomeration  of  technologies 
selected  to  be  part  of  the  concept  system  with  a  general  vision  of  their  eventual 
arrangement  with  one  another. 

Modified  Su-Field  Diagrams  -  The  Su-field  Diagrams  modified  to  reflect  the  new 
functionality  allowed  by  selected  technologies  for  the  concept  system  to  be  developed. 
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Engineering  Technologies  Requirements  Data  -  Requirements  extracted  from  the 
Alternative  Concept  Descriptions,  Modified  Su-field  diagrams,  and  put  onto  a 
Requirements  Management  Application  database  with  other  requirements  data  for 
subsequent  tracking  and  analysis. 

Concept  System  Conflicts  -  System  characteristics  working  against  one  another 
causing  limitations  in  the  concept  system  that  prohibits  the  system  from  realizing  the 
full  functionality  desired.  This  provides  iterative  feedback  to  designated  prior  activities. 

Engineering  Process  Map  -  A  flowchart  detailing  on  an  engineering  level  the 
activities  and  events  involved  with  the  operation  under  study.  The  map  is  developed 
by  Subject  Matter  Experts  having  intimate  experience  with  and  immediate  knowledge 
of  the  operation  being  studied. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  ail  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Initial  Concept  Schematic  -  An  initial  generalized  diagram  depicting  the  Concept 
System. 

Final  Su-Field  Diagrams  -  The  Su-field  Diagram  further  modified  in  this  activity  to  be 
consistent  with  the  concept  system  depicted  by  the  Initial  Concept  Schematic. 

Engineering  Concepts  Requirements  Data  -  Requirements  extracted  from  the  Final 
Engineering  Process  Maps,  the  Final  Su-Field  Diagrams,  and  the  Initial  Concept 
Schematics:  and  put  onto  a  Requirements  Management  Application  database  with 
other  requirements  data  for  subsequent  tracking  and  analysis. 

Final  Engineering  Process  Map  -  The  Engineering  Process  Map  modified  to  be 
consistent  with  the  concept  system  depicted  by  the  Initial  Concept  Schematic. 

Mechanisms: 

Personnel  -  Engineers  and  other  government  and  contracted  employees  having 
cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 
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Axiomatic  Design  Methods  -  Regular  means  based  on  a  systematic  set  of  rules 
for  the  synthesis  of  concept  systems. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A3.4  Develop  Engineering  Alternative  Concepts 

Develops  the  engineering  concepts  into  a  truly  integrated  and  balanced  engineering 
solutions  that  include  estimates  of  their  likelihood  to  become  a  reality  as  well  as  their  cost 
(Figure  A-A3(d)). 


Project  Management  Plan 


Facility 


Figure  AA3(d)  Develop  Engineering  Concepts 


Inputs: 

Initial  Concept  Schematics  -  The  initial  generalized  diagrams  depicting  the  Concept 
Systems. 

Engineering  Concepts  Requirements  Data  -  Requirements  extracted  from  the  Final 
Engineering  Process  Maps,  the  Final  Su-Field  Diagrams,  and  the  Initial  Concept 
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Schematics;  and  put  onto  a  Requirements  Management  Application  database  with 
other  requirements  data  for  subsequent  tracking  and  analysis 

Final  Engineering  Process  Map  -  The  Engineering  Process  Map  modified  to  be 
consistent  with  the  concept  system  depicted  by  the  Initial  Concept  Schematics. 

Final  Su>Field  Diagrams  -  The  final  modified  Su-field  Diagram. 

Engineering  Functional  Requirements  Specifications  -  Delineates  on  the 
engineering  level  the  functional  capabilities  for  engineering  to  address  in  subsequent 
development  of  the  Concept  Systems. 

Gap  Analysis  Report  -  A  description  of  the  gap  measures  determined.  The  report 
may  include  descriptions  of  the  system  conflicts  causing  a  gap,  and  the  functional 
system  requirements  aimed  at  closing  a  gap. 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Engineering  Data  for  Alternative  Designs  -  Concept  System  data  collated  in  the 
form  of  a  Concept  Engineering  Package  providing  a  Concept  Schematic,  any  Software 
Design  Documents  that  may  be  applicable,  Material  Lists,  a  Short  System  Description, 
a  Concept  System  Specification,  and  a  likelihood  estimate  for  the  Concept  System’s 
prospects  of  actually  being  developed. 

Cost  Data  for  Alternative  Designs  -  Rough  order  of  magnitude  estimates  of 
acquisition  costs  in  relative  terms,  as  well  as  estimates  of  total  ownership  costs  of  the 
subject  concept  systems  under  study. 

Concept  Systems  Conflicts  -  Concept  System  characteristics  working  against  one 
another  causing  limitations  in  the  concept  system  that  prohibits  the  system  from 
realizing  the  full  functionality  desired.  This  provides  iterative  feedback  to  the  predicate 
activity  of  Selecting  Alternative  Engineering  Concepts. 
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Mechanisms: 

Personnel  -  Engineers,  cost  estimators,  manning  estimators,  Software  Experts,  and 
other  government  and  contracted  employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Acquisition  Cost  Application  -  software  upon  which  acquisition  cost  models  reside. 

Manning  Application  -  software  upon  which  manning  models  reside. 

Total  Ownership  Cost  Application  -  software  upon  which  models  for  computing 
total  ownership  costs  reside. 

Assorted  Engineering  Applications  -  the  body  of  software  upon  which  models 
for  computing  engineering  characteristics  reside. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  subject  activity. 
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A3.4.1  Acquire  Engineering  and  Cost  Component  Models 

Develops  new  or  obtains  existing  engineering  models  as  well  as  cost,  and  manning 
models  that  provide  for  the  computation  of  engineering,  cost  and  manning  characteristics 
of  the  key  components  of  the  Concept  System  (Figure  A-A3.4(a)). 


Figure  A-A3.4(a)  Develop  Engineering  Alternative  Concepts 


Inputs: 

Engineering  Concepts  Requirements  Data  -  Requirements  extracted  from  the  Final 
Engineering  Process  Maps,  the  Final  Su-Field  Diagrams,  and  the  Initial  Concept 
Schematics;  and  put  onto  a  Requirements  Management  Application  database  with 
other  requirements  data  for  subsequent  tracking  and  analysis. 

Initial  Concept  Schematic  -  The  initial  generalized  diagram  depicting  the  Concept 
System. 
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Final  Su-Field  Diagram -The  final  modified  Su-field  Diagram. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Engineering  and  Cost  Component  Models  -  Calculation  routines  for  computing  the 
engineering,  cost,  and  manning  characteristics  of  the  Concept  System(s)  components. 

Engineering  Model  Requirements  Data  -  Requirements  extracted  from  the 
engineering  models;  and  put  onto  a  Requirements  Management  Application  database 
with  other  requirements  data  for  subsequent  tracking  and  analysis. 

Mechanisms: 

Personnel  -  Engineers,  cost  estimators,  manning  estimators,  and  other  government 
and  contracted  employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Acquisition  Cost  Application  -  software  upon  which  acquisition  cost  models 
reside. 

Manning  Application  -  software  upon  which  manning  models  reside. 

Total  Ownership  Cost  Application  -  software  upon  which  models  for  computing 
total  ownership  costs  reside. 

Assorted  Engineering  Applications  -  the  body  of  software  upon  which  models 
for  computing  engineering  characteristics  reside. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  subject  activity. 
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A3.4.2  Integrate  Engineering  and  Cost  Component  Models 

Synthesizes  the  conglomeration  of  models  residing  on  their  respective  applications  into 
one  cohesive  interacting  whole  (Figure  A-A3.4(b)). 


Figure  A-A3.4(b)  Develop  Engineering  Alternative  Concepts 
Inputs: 

Engineering  and  Cost  Component  Models  -  Calculation  routines  for  computing  the 
characteristics  of  Concept  System  components. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
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development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Integrated  Engineering  Models  for  Alternative  Systems  -  The  medium  in  which  the 
connected  engineering,  cost,  and  manning  algorithms  reside. 

Mechanisms: 

Personnel  -  Engineers,  Software  experts,  and  other  government  and  contracted 
employees  having  cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Concept  Investigation  Environment  Application  -  The  software  that  brings 
together  the  respective  applications  upon  which  the  individual  engineering,  cost, 
and  manning  models  reside. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities.  Facility  for  this  particular  activity  includes  a  Virtual  Private 
Network  (VPN)  for  secure  distributed  computing. 
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A3.4.3  Conduct  Parameter  Design 

Exercises  the  Concept  Investigation  Environment  by  varying  and  balancing  key  design 
parameters  with  one  another  to  achieve  a  set  of  viable,  or  best  concept  system  solutions. 
The  concept  design  is  improved  here  to  a  point  where  desired  systems  characteristics  are 
maximized  without  detriment  to  other  desired  system  characteristics  (Figure  AA3.4(c)). 


Facility 


Figure  AA3.4(c)  Develop  Engineering  Alternative  Concepts 


Inputs: 

Integrated  Engineering  Models  for  Alternative  Systems  -  The  medium  in  which  the 
connected  engineering,  cost,  and  manning  algorithms  reside. 

Engineering  Model  Requirements  Data  -  Requirements  extracted  from  the 
engineering  models;  and  put  onto  a  Requirements  Management  Application  database 
with  other  requirements  data  for  subsequent  tracking  and  analysis. 

Engineering  Functional  Requirements  Specifications  -  Delineates  on  the 
engineering  level  the  functional  capabilities  for  engineering  to  address  in  subsequent 
development  of  the  Concept  Systems. 
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Gap  Analysis  Report  -  A  description  of  the  gap  measures  determined.  The  report 
may  include  descriptions  of  the  system  conflicts  causing  a  gap,  and  the  functional 
system  requirements  aimed  at  closing  a  gap. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Concept  System  Conflicts  -  System  characteristics  working  against  one  another 
causing  limitations  in  the  concept  system  that  prohibits  the  system  from  realizing  the 
full  functionality  desired.  This  provides  iterative  feedback  to  designated  prior  activities. 

Raw  Data  for  Alternative  Systems  -  Concept  Investigation  Output  data  depicting  a 
balanced  set  of  system  characteristics  in  electronic  spreadsheet  format. 

Engineering  Balance  Requirements  Data  -  Requirements  extracted  from  the  Raw 
Data  for  Alternative  Systems;  and  put  onto  a  Requirements  Management  Application 
database  with  other  requirements  data  for  subsequent  tracking  and  analysis. 

Mechanisms: 

Personnel  -  Engineers,  and  other  government  and  contracted  employees  having 
cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Engineering  Concept  Investigation  Environment  Application  -  The  software 
that  brings  together  the  respective  applications  upon  which  the  individual 
engineering,  cost,  and  manning  algorithms  reside. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities.  Facility  for  this  particular  activity  includes  a  Virtual  Private 
Network  (VPN)  for  secure  distributed  computing. 
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A3.4.4  Assemble  Concept  Engineering  Package 

Collates  Concept  System  data  into  a  cohesive  package.  Requirements  documented  on 
the  Requirements  Management  Application  Database  are  brought  into  a  cohesive 
Concept  System  Specification.  If  numerous  Concept  System  options  are  developed,  this 
activity  also  ranks  the  concept  as  to  their  likelihood  for  development  (Figure  AA3.4(d)). 


Figure  A-A3.4(d)  Develop  Engineering  Alternative  Concepts 


Inputs: 

Raw  Data  for  Alternative  Systems  -  Concept  Investigation  Output  data  depicting  a 
balanced  set  of  system  characteristics  in  electronic  spreadsheet  format. 
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Engineering  Balance  Requirements  Data  -  Requirements  extracted  from  the  Raw 
Data  for  Alternative  Systems;  and  put  onto  a  Requirements  Management  Application 
database  with  other  requirements  data  for  subsequent  tracking  and  analysis. 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Final  Engineering  Process  Map  -  The  Engineering  Process  Map  modified  to  be 
consistent  with  the  concept  system  depicted  by  the  Initial  Concept  Schematics. 

Controls; 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs; 

Engineering  Data  for  Alternative  Designs  -  Concept  System  data  collated  in  the 
form  of  a  Concept  Engineering  Package  providing  a  Concept  Schematic,  any  Software 
Design  Documents  that  may  be  applicable,  Material  Lists,  a  Short  System  Description, 
a  Concept  System  Specification,  and  a  likelihood  estimate  for  the  Concept  System’s 
prospects  of  actually  being  developed. 

Cost  Data  for  Alternative  Designs  -  Rough  order  of  magnitude  estimates  of 
acquisition  costs  in  relative  terms,  as  well  as  estimates  of  total  ownership  costs  of  the 
subject  Concept  Systems  under  study. 

Mechanisms; 

Personnel  -  Engineers,  and  other  government  and  contracted  employees  having 
cognizance  in  the  activity. 

Tools  -  Accepted  methods  that  support  the  activity. 

Requirements  Management  Application  -  Software  designed  handle 
requirements  extracted  from  output  documents.  The  software  is  to  track 
requirements  from  their  inception  to  application  in  support  of  requirements  and 
design  analysis  throughout  the  engineering  activities. 

Facility  -  Building  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 


MTS  Technologies,  Inc. 


159 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


A4  Build  Integrated  M&S  Environment 

Planning,  Designing,  Implementing  and  Testing  the  federation  of  models  and  simulations 
to  meet  the  requirements  established  in  the  Experiment  Plan  (Figure  AAO(d)). 


Inputs: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 
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Alternative  Design  Data  -  Design  information  (design  concept,  description  and 
associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Domain  Data  - 

Hardware  Components  - 

Software  Components  - 

Existing  Code  - 

Controls: 

Project  Management  Plan  -  Provides  the  overall  direction  for  all  phases  of  the 
WARCON  process  to  include  tasks,  organization,  program  resources  and  costs, 
software  development,  products,  schedules  and  milestones.  The  Software 
Development  Plan  is  included  within  this  Plan. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Modeling  and  Simulation  (M&S)  Availability/Capability-  Identification  and 
assessment  of  the  models  and  simulations  available  to  support  the  analysis,  and  their 
capabilities,  for  potential  inclusion  into  the  integrated  system/federation. 

Hardware  (HW)/Software  (SW)  Availability/Capability  - 
Outputs: 

System  Sub-System  Specifications  (SSS)  - 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

M&S  Inventory  - 
Operator  Procedures - 

Validation  and  Verification  Report  -  Results  and  assessment  based  on  the  accepta¬ 
bility  criteria  that  the  built  system  is  validated  and  verified  given  the  intended  use. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.1  Plan  M&S  Environment 

Reviewing  the  Experiment  Plan  and  determining  that  all  required  information  has  been 
identified  to  design  the  system  and  develop  the  System  Requirements  Document  (Figure 
A-A4(a)). 


Figure  A-A4(a)  WARCON  Build  Integrated  M&S  Environment 


Inputs: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Problem  Definition,  Scenario,  and  M&S  System  Requirements  -  Description  of  the 
unconstrained  functional  requirements  for  the  M&S  System  needed  to  address  all 
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aspects  of  the  customer  problem  statement,  including  representations  of  the  subject 
system,  technologies,  and  operational  scenarios. 

Alternative  Design  Data  -  Design  information  (design  concept,  description  and 
associated  cost)  for  alternate  subject  system  designs  to  be  analyzed 

Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

System  Requirements  Document  (SRD)  -  Identifies  functions  and  capabilities 
needed  for  the  integrated  system,  and  may  include  engineering  design,  software 
development,  warfare  operations,  and  cost  models  and  simulations. 

Mechanisms: 

Personnel  -  Government  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.2  Design  M&S  Environment 

Identifying  the  hardware  and  software  required  to  build  the  integrated  system  (Figure  A- 
A4(b)). 
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Facility 


Figure  AA4(B)  WARCON  Build  Integrated  M&S  Environment 


Inputs: 

System  Requirements  Document  (SRD)  -  Identifies  functions  and  capabilities 
needed  for  the  integrated  system,  and  may  include  engineering  design,  software 
development,  warfare  operations,  and  cost  models  and  simulations. 

Alternative  Design  Data  -  Design  information  (design  concept,  description  and 
associated  cost)  for  alternate  subject  system  designs  to  be  analyzed 
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Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Domain  Data  - 
Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Modeling  and  Simulation  (M&S)  Availability/Capability-  Identification  and 
assessment  of  the  models  and  simulations  available  to  support  the  analysis,  and  their 
capabilities,  for  potential  inclusion  into  the  integrated  system/federation. 

Hardware/Software  Availability/Capability  - 

Outputs: 

SSS- 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Detailed  Design  -  Contains  the  specific  hardware,  software  components/algorithms, 
data  requirements  for  the  integrated  system.. 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Acceptability  Criteria  (AC)  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.2.1  Generate  System  Sub-System  Specification 

Building  a  database  identifying  the  specification  requirements  to  design  the  system 
(derived  from  the  SRD)  (Figure  A-A4.2(a)). 


Facility 


Figure  A-A4.2(a)  Design  M&S  Environment 


Inputs: 

System  Requirements  Document  (SRD)  -  Identifies  functions  and  capabilities 
needed  for  the  integrated  system,  and  may  include  engineering  design,  warfare 
operations,  and  cost  models  and  simulations. 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.2.2  Perform  M&S  Knowledge  Acquisition/Engineering  (KA/E) 

Performing  a  rigorous  process  of  decomposing  high-level  requirements  to  acceptability 
criteria  (AC)  (Figure  AA4.2(b)). 


Facility 


Figure  AA4.2(b)  Design  M&S  Environment 


Inputs: 

Alternative  Design  Data  -  Design  information  (design  concept,  description  and 
associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Domain  Data  - 

Required  Data  Item  - 
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Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Modeling  and  Simulation  (M&S)  Availability/Capability  -  Identification  and 
assessment  of  the  models  and  simulations  available  to  support  the  analysis,  and  their 
capabilities,  for  potential  inclusion  into  the  integrated  system/federation. 

Outputs: 

Acceptability  Criteria  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 

Physical  Systems  Description  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.2.2.1  Identify  and  Select  Mission  Tasks 

(Figure  A-A4.2.2(a)). 


Facility 


Figure  A-A4.2.2(a)  Perform  M&S  Knowledge  Acquisition/Engineering 


Inputs: 

Alternative  Design  Data  -  Design  information  (design  concept,  description  and 
associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Domain  Data  - 
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Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Modeling  and  Simulation  (M&S)  Availability/Capability-  Identification  and 
assessment  of  the  models  and  simulations  available  to  support  the  analysis,  and  their 
capabilities,  for  potential  inclusion  into  the  integrated  system/federation. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Selected  Tasks  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations,  and  COTS  that 
support  the  modeling  and  analysis  environments. 

Facility  - 
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A4.2.2.2  Develop  Task  Procedure  Descriptions 

(Figure  A-A4.2.2(b)) 


Facility 


Figure  A-A4.2.2(b)  Perform  M&S  Knowledge  Acquisition/Engineering 


Inputs: 

Selected  Tasks - 

Alternative  Design  Data  -  Design  information  (design  concept,  description  and 
associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Domain  Data  - 
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Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Task  Procedures  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations,  and  COTS  that 
support  the  modeling  and  analysis  environments. 

Facility  - 
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A4.2.2.3  Identify  Collective  Physical  Systems 

(Figure  A-A4.2.2(c)) 


Facility 


Figure  A-A4.2.2(c)  Perform  M&S  Knowledge  Acquisition/Engineering 


Inputs: 

Task  Procedures  - 

Alternative  Design  Data  -  Design  information  (design  concept,  description  and 
associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Domain  Data  - 
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Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Physical  Systems  List  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations,  and  COTS  that 
support  the  modeling  and  analysis  environments. 

Facility  - 
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A4.2.2.4  Develop  Physical  System  Descriptions 

(Figure  A-A4.2.2(d)) 


Facility 


Figure  A-A4.2.2(d)  Perform  M&S  Knowledge  Acquisition/Engineering 


Inputs: 

Physical  Systems  List  - 

Alternative  Design  Data  -  Design  information  (design  concept,  description  and 
associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Domain  Data  - 
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Required  Data  Item- 
Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Physical  System  Description  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations,  and  COTS  that 
support  the  modeling  and  analysis  environments. 

Facility  - 
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A4.2.2.5  Develop  Acceptability  Criteria  (AC) 

(Figure  A-A4.2.2(e)) 


Facility 


Figure  AA4.2.2(e)  Perform  M&S  Knowledge  Acquisition/Engineering 


Inputs: 

Physical  System  Description 
Task  Procedures  - 
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Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Acceptability  Criteria  (AC)  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations,  and  COTS  that 
support  the  modeling  and  analysis  environments. 

Facility  - 


MTS  Technologies,  Inc. 


179 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


A4.2.3  Develop  Detailed  Design  for  M&S  System 

Following  a  rigorous  knowledge  acquisition/engineering  process  to  decompose 
requirements  to  a  level  capable  of  being  written  to  a  design  that  can  be  built  in  hardware 
or  coded  in  software. 


Facility 


Figure  A-A4.2(c)  Design  M&S  Environment 


Inputs: 

Acceptability  Criteria  (AC)  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 

Physical  System  Description  - 
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Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Modeling  and  Simulation  (M&S)  Availability/Capability-  Identification  and 
assessment  of  the  models  and  simulations  available  to  support  the  analysis,  and  their 
capabilities,  for  potential  inclusion  into  the  integrated  system/federation. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

HW/SW  Availability/Capability  - 
Outputs: 

High  Level  Design  - 
Required  Data  Items  - 
Detailed  Design  - 
System  Test  Document  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations,  and  COTS  that 
support  the  modeling  and  analysis  environments. 

Facility  - 
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A4.2.3.1  Develop  System  Requirements  Specification  (SRS) 
(Figure  A-A4.2.3(a)) 


Facility 


Figure  A-A4.2.3(a)  Develop  Detailed  Design  For  M&S  System 


Inputs: 

Acceptability  Criteria  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Outputs: 

SRS  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.2.3.2  Develop  High  Level  Design  (HLD) 

Developing  an  architecture  that  is  sufficient  to  describe  the  intended  integrated  system 
components  and  data  requirements. 


Facility 


Figure  A-A4.2.3(b)  Develop  Detailed  Design  For  M&S  System 


Inputs: 
SRS  - 
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Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Modeling  and  Simulation  (M&S)  Availability/Capability-  Identification  and 
assessment  of  the  models  and  simulations  available  to  support  the  analysis,  and  their 
capabilities,  for  potential  inclusion  into  the  integrated  system/federation. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Hardware/Software  Availability/Capability  - 
Outputs: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program 
review  approval. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.2.3.3  Develop  Detailed  Design 

Performing  a  further  decomposition  of  the  HLD  that  is  of  sufficient  detail  to  describe  the 
hardware  and  software  components  and  how  to  build/code  those  components. 


Facility 


Figure  A-A4.2.3(c)  Develop  Detailed  Design  For  M&S  System 


Inputs: 

High  Level  Design  -  Plan  for  building  the  Integrated  System;  requires  program  review 
approval. 

Physical  Systems  Descriptions  - 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Required  Data  Item  - 

Detailed  Design  -  contains  the  specific  hardware,  software  components/algorithms, 
and  data  requirements  for  the  integrated  system.. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.2.3.4  Develop  System  Test  Document  (STD) 

(Figure  A-A4.2.3(d)) 


Facility 


Figure  A-A4.2.3(d)  Develop  Detailed  Design  For  M&S  System 


Inputs: 

Detailed  Design  -  contains  the  specific  hardware,  software  components/algorithms, 
and  data  requirements  for  the  integrated  system. 
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Controls: 

Subsystem  Specification  (SSS)  -Database  of  requirements  from  the  System 
Requirements  Document  that  allows  for  requirements  traceability  during  system 
design/implementation/test. 

Outputs: 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.3  Implement  and  Test  M&S  Environment 

Coding  and  building  the  software/hardware  integrated  system  and  associated  testing. 


Software 

Development 
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Figure  A-A4(c)  Build  Integrated  M&S  Environment 
Inputs: 

Detailed  Design  -  contains  the  specific  hardware,  software  components/algorithms, 
and  data  requirements  for  the  integrated  system.. 

Software  Components  - 

Hardware  Components  - 

Acceptability  Criteria  -  Testable  requirements  that  are  derived  from  “real  world" 
capabilities  based  on  intended  use  of  the  system  being  built. 
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Existing  Codes  - 
Controls: 

System  Test  Document  -  Test  criteria  that  are  used  to  verify  the  built  system  against 
the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability  criteria. 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Hardware/Software  Availability/Capability  - 
Outputs: 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Verification  and  Validation  (V&V)  Report  -  Results  and  assessment  based  on  the 
acceptability  criteria  that  the  built  system  is  verified  and  validated  given  the  intended 
use. 

Operator  Procedures  - 
M&S  Inventory  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.1  Procure  and  Configure  Hardware 

(Figure  A-A4.3(a)) 


HW/SW  Availability/Capability 


■Tested  M&S  Environment — V 

- M&S  Inventory - y 

| - Operator  Procedures - ► 

- V&V  Report - ► 


Personnel 


Tools 


Facility 


Figure  AA4.3(a)  Implement  and  Test  M&S  Environment 


Inputs: 

Hardware  Components  - 
Software  Components  - 
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Detailed  Design  -  Contains  the  specific  hardware,  software  components/algorithms, 
data  requirements  for  the  integrated  system.. 

Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

HW/SW  Availability/Capability  - 
Outputs: 

Configured  Hardware  Inventory  - 
Configured  Hardware  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.1.1  Select  and  Procure  Hardware/Software 
(Figure  A-A4.3(a)) 


Figure  A-A4.3(a)  Procure  and  Configure  Hardware 
Inputs: 

Hardware  Components  - 
Software  Components  - 

Detailed  Design  -  Contains  the  specific  hardware,  software  components/aigorithms, 
data  requirements  for  the  integrated  system.. 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

HW/SW  Availability/Capability  - 
Outputs: 

Procured  Hardware/Software  Components  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.1.2  Integrate  and  Configure  Hardware 

(Figure  A-A4.3(b)) 


Facility 


Figure  A-A4.3(b)  Procure  and  Configure  Hardware 


Inputs: 

Procured  Hardware/Software  Components 
Configure  Hardware  Defects  Report  - 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Configured  Hardware  Inventory  - 
Configured  Hardware  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  - 
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A4.3.1.3  Test  Configured  Hardware 

(Figure  A-A4.3(c)) 


Figure  A-A4.3(c)  Procure  and  Configure  Hardware 
Inputs: 

Configured  Hardware  - 
Controls: 

System  Test  Document¬ 
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Outputs: 

Tested  Configured  Hardware  - 
Configure  HW  Defects  Reports  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.2  Develop  and  Verify  Code 

(Figure  A-A4.3(b)) 


Facility 


Figure  AA4.3(b)  Implement  and  Test  M&S  Environment 
Inputs: 

Detailed  Design  -  Contains  the  specific  hardware,  software  components/algorithms, 
data  requirements  for  the  integrated  system. 

Existing  Code  - 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Outputs: 

Verified  Code  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.2.1  Develop  Code 

(Figure  A-A4.3.2(a)) 
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Figure  A-A4.3.2(a)  Develop  and  Verify  Code 


Inputs: 

Detailed  Design  -  Contains  the  specific  hardware,  software  components/algorithms, 
data  requirements  for  the  integrated  system. 

Existing  Code  - 

Code  Verification  Results  - 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Code  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.2.2  Verify  Code  Functionality 

(Figure  A-A4.3.2(b)) 
i 


Facility 

Figure  AA4.3.2(b)  Develop  and  Verify  Code 

Inputs: 

Code  - 

Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 
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System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Outputs: 

Verified  Code  - 

Code  Verification  Results  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.3  Integrate,  Verify  and  Validate  M&S  Environment 
(Figure  A-A4.3(c)) 


Facility 


Figure  A-A4.3(c)  Implement  and  Test  M&S  Environment 
Inputs: 

Tested  Configured  Hardware - 
Verified  Code  - 
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Detailed  Design  -  Contains  the  specific  hardware,  software  components/algorithms, 
data  requirements  for  the  integrated  system. 

Configured  Hardware  Inventory- 

Acceptability  Criteria  (AC)  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 

Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Outputs: 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

M&S  Inventory - 

Operator  Procedures  - 

Validation  and  Verification  Report - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.3.1  Install  Code 

(Figure  A-A4.3.3(a)) 


Figure  A-A4.3.3(a)  Integrate,  Verify  and  Validate  M&S  Environment 


Inputs: 

Tested  Configured  Hardware - 
Verified  Code  - 

Detailed  Design  -  Contains  the  specific  hardware,  software  components/algorithms, 
data  requirements  for  the  integrated  system. 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Installed  Code  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.3.2  Generate  M&S  Environment  Inventory 

(Figure  A-A4.3.3(b)) 


Figure  A-A4.3.3(b)  Integrate,  Verify  and  Validate  M&S  Environment 


Inputs: 

Installed  Code  - 
Configured  HW  Inventory  - 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

M&S  Inventory - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.3.3  Develop  Operator  Procedures 

(Figure  A-A4.3.3(c)) 


Facility 


Figure  AA4.3.3(c)  Integrate,  Verify  and  Validate  M&S  Environment 


Inputs: 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Verification  Results  - 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

Outputs: 

Operator  Procedures  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.3.4  Verify  and  Validate  M&S  Environment 

(Figure  A-A4.3.3(d)) 


Figure  A-A4.3.3(d)  Integrate,  Verify  and  Validate  M&S  Environment 
Inputs: 

Operator  Procedures  - 

Tested  M&S  Environment-  Integrated  System  after  full  testing. 

Acceptability  Criteria  (AC)  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Outputs: 

Validation  and  Verification  Report  -  Results  and  assessment  based  on  the 
acceptability  criteria  that  the  built  system  is  validated  and  verified  given  the  intended 
use. 

Verification  Results  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.3.4.1  Verify  M&S  Environment  Functionality 

(Figure  A-A4.3.3.4(a)) 


Facility 


Figure  A-A4.3. 3.4(a)  Validate  and  Verify  M&S  Environment 


Inputs: 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Operator  Procedures  - 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Outputs: 

Verification  Results  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.3.4.2  Assess  M&S  Environment  Validity 

(Figure  A-A4.3.3.4(b)) 


Facility 


Figure  AA4.3.3.4(b)  Validate  and  Verify  M&S  Environment 


Inputs: 

Verification  Results - 

Acceptability  Criteria  (AC)  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Outputs: 

Validation  Assessment  - 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A4.3.3.4.3  Develop  V&V  Report 

(Figure  A-A4.3.3.4(c)) 


Facility 


Figure  AA4.3.3.4(c)  Validate  and  Verify  M&S  Environment 
Inputs: 

Validation  Assessment  - 

Acceptability  Criteria  (AC)  -  Testable  requirements  that  are  derived  from  “real  world” 
capabilities  based  on  intended  use  of  the  system  being  built. 
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Controls: 

Software  Development  Plan  -  Identifies  software  to  be  procured  or  written  to  conduct 
an  experiment. 

System  Test  Document  (STD)  -  Test  criteria  that  are  used  to  verify  the  built  system 
against  the  detailed  design  and  assist  in  validating  the  system  against  the  acceptability 
criteria. 

Outputs: 

V&V  Report  - 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility - 
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A5  Conduct  Experiment 

Performing  the  experiment  in  accordance  with  the  Project  Management  Plan  and 
Experiment  Plan  (Figure  A-AO(e)). 


Inputs: 

Resource  Availability  Data  -  The  access  to  time,  people,  equipment  and  facilities 
required  to  conduct  the  experiment(s). 

Resource  Requirements  Data -The  time,  people,  equipment  and  facilities  necessary 
to  conduct  the  experiment(s). 

M&S  Inventory -M&S  hardware  and  software  required  for  experiment  execution. 
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Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Operator  Procedures  -  Procedures  used  by  M&S  operators  during  experiment 
execution. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Experiment  Data  -  Results  of  the  experiment  for  all  parts  of  the  experiment  as 
directed  by  the  Experiment  Plan.  Includes  performance  and  cost  data  for  each 
experiment  excursion. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.1  Plan  Experiment  Execution 

Identifying  requirements,  availability  and  resources  (personnel,  Integrated  M&S  System) 
required  to  perform  the  experiment,  develop  a  detailed  experiment  concept  of  operations 
(CONOPS),  and  produce  an  experiment  schedule  (Figure  A-A5(a)). 
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Figure  AA5(a)  Conduct  Experiment 


Inputs: 

Resource  Availability  Data  -  The  access  to  time,  people,  equipment  and  facilities 
required  to  conduct  the  experiment(s). 

Resource  Requirements  Data- The  time,  people,  equipment  and  facilities  necessary 
to  conduct  the  experiment(s). 
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M&S  Inventory  -  M&S  hardware  and  software  required  for  experiment  execution. 
Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  progam  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 

Experiment  Execution  Schedule  -  Detailed  schedule  identifying  the  timeline  for  all 
the  resources  required  to  perform  the  experiment 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 


MTS  Technologies,  Inc. 


225 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


A5.1.1  Develop  Experiment  CONOPS 

Developing  a  concept  of  operations  for  experiment  scheduling  and  execution,  using  the 
Experiment  Plan,  to  include  a  sequence  of  experiment  events  for  Integrated  M&S  System 
Data  Production  Runs  and  Quick-Look  Analysis  (Figure  A-A5.1(a)). 


Tools  (Analysis 
Tools) 


Figure  A-A5.1(a)  Plan  Experiment  Execution 


Inputs: 

M&S  Inventory  -  Hardware  and  software  required  for  experiment  execution. 
Tested  M&S  Environment  -  Integrated  System  after  full  testing. 
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Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs), 

analysis  methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.1.2  Determine  Experiment  Resource  Requirements 

Identifying  all  resources,  such  as  personnel  and  tools,  required  to  perform  the  experiment. 
Resource  requirements  will  include  facilities,  numbers  of  analysts,  systems  engineers  and 
operators,  experiment  subject  matter  experts  (if  required  in  the  Experiment  Plan)  and  the 
estimated  sequence  and  length  of  time  each  is  required  (Figure  AA5.1(b)). 


Tools  (Analysis 
Tools) 


Figure  A-A5.1(b)  Plan  Experiment  Execution 


Inputs: 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 
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Resource  Requirements  Data -The  time,  people,  equipment  and  facilities  necessary 
to  conduct  the  experiment(s). 

Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Required  Experiment  Resources  -  List  resources  required  for  experiment  execution. 
Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A5.1.3  Schedule  Experiment 

Developing  a  schedule,  to  include  availability  of  system  engineers,  analysts,  SMEs,  and 
modeling  and  simulation  run  time  for  the  experiment  (Figure  A-A5.1(c)). 


Tools  (Analysis  Tools) 


Figure  AA5.1(c)  Plan  Experiment  Execution 


Inputs: 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 

Required  Experiment  Resources  -  List  resources  required  for  experiment  execution. 

Resource  Availability  Data  -  The  access  to  time,  people,  equipment  and  facilities 
required  to  conduct  the  experiment(s). 
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Controls: 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Experiment  Execution  Schedule  -  Detailed  schedule  identifying  the  timeline  for  all 
the  resources  required  to  perform  the  experiment 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A5.2  Execute  Experiment 

Employing  the  Tested  Integrated  System  to  perform  the  experiment.  Will  include  quick- 
look  analysis  of  experiment  data  and  multiple  model  runs  for  Baseline/Comparison  and  all 
Excursion  Cases  (Figure  A-A5(b)). 


Facility 


Figure  A-A5(b)  Conduct  Experiment 


Inputs: 

Experiment  Execution  Schedule  -  Detailed  schedule  identifying  the  timeline  for  all 
the  resources  required  to  perform  the  experiment 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 
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Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Operator  Procedures  -  Procedures  used  by  M&S  operators  during  experiment 
execution. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Baseline/Comparison  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S 
System  for  all  combinations  of  variables  and  scenario  excursions  for  the 
Baseline/Comparison  Case  as  directed  in  the  Experiment  Plan. 

Excursion  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S  System  for 
all  combinations  of  variables  and  scenario  variations  for  all  experiment  excursion 
cases  as  directed  in  the  Experiment  Plan. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.1  Review  Experiment  Plan  and  CONOPS 

Reviewing  the  Experiment  Plan  and  CONOPS  with  experiment  personnel  at  the  beginning 
of  the  experiment  execution  session,  and  revise  as  required  to  factor  in  unexpected 
constraints  or  schedule  changes  (Figure  A-A5.2(a)). 


Facility 


Figure  A-A5.2(a)  Execute  Experiment 


Inputs: 

Experiment  Excursion  Schedule  -  Detailed  schedule  identifying  the  timeline  for  all 
the  resources  required  to  perform  the  experiment 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 
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Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Experiment  Execution  Plan  -  Document  that  defines  how  the  execution  of  the 
experiment  will  be  conducted. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A5.2.2  Perform  Baseline/Comparison  Case  Runs 

Conducting  the  experiment  as  defined  in  the  Experiment  Plan  for  all  combinations  of 
variables  and  scenario  excursions  (Figure  A-A5.2(b)). 


Figure  AA5.2(b)  Execute  Experiment _ 

Inputs: 

Experiment  Execution  Plan  -  Document  that  defines  how  the  execution  of  the 
experiment  will  be  conducted. 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 

Tested  M&S  Environment  -  integrated  System  after  full  testing. 


MTS  Technologies,  Inc. 


236 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


Operator  Procedures  -  Procedures  used  by  M&S  operators  during  experiment 
execution. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Baseline/Comparison  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S 
System  for  all  combinations  of  variables  and  scenario  excursions  for  the 
Baseline/Comparison  Case  as  directed  in  the  Experiment  Plan. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.2.1  Review  input  Data  for  Baseline/Comparison  Case 

Reviewing  experiment  input  data  by  Analysts  and  M&S  System  personnel  for  experiment 
data  production  runs  (Figure  A-A5.2.2(a)). 


Facility 


Figure  A-A5.2.2(a)  Perform  Baseline/Comparison  Case  Runs 
Inputs: 

Experiment  Execution  Plan  -  Document  that  defines  how  the  execution  of  the 
experiment  will  be  conducted. 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 


MTS  Technologies,  Inc. 


238 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


Next  Run  Input  Data  -  List  of  input  data  for  the  next  Baseline/Comparison  Case  Data 
Production  Run. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Reviewed  Baseline/Comparison  Data  Inputs  -  List  of  reviewed 
Baseline/Comparison  Data  Inputs  for  upcoming  experiment  data  production  runs. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.2.2  Execute  Baseline/Comparison  M&S  Run 

Performing  a  Baseline/Comparison  Case  Data  Production  Run  in  accordance  with  the 
Experiment  Plan  and  Experiment  Execution  CONOPS  (Figure  A-A5.2.2(b)). 


Experiment  Plan 


Facility 


Figure  A-A5.2.2(b)  Perform  Baseline/Comparison  Case  Runs 


Inputs: 

Reviewed  Baseline/Comparison  Data  Inputs  -  List  of  reviewed 
Baseline/Comparison  Data  Inputs  for  upcoming  experiment  data  production  runs. 

Tested  R/I&S  Environment  -  Integrated  System  after  full  testing. 

Operator  Procedures  -  Procedures  used  by  M&S  Operators  during  experiment 
execution. 
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Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Baseline/Comparison  Run  Output  Data  -  Baseline/Comparison  Experiment  Run 
Output  Data. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.2.3  Perform  Baseline/Comparison  Quick  Look  Data  Analysis 

Reviewing  the  output  data  from  each  data  production  run  by  analysts  and  M&S  personnel 
to  determine  if  experiment  data  requirements  have  been  met  for  the  Baseline/Comparison 
Case  and  to  determine  if  subsequent  data  production  runs  are  required  (Figure  A 
A5. 2.2(c)). 
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Figure  AA5.2.2(c)  Perform  Baseline/Comparison  Case  Runs 


Inputs: 

Baseline/Comparison  Run  Output  Data  -  List  Baseline/Comparison  Experiment  Run 
Output  Data. 
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Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Baseline/Comparison  Quick  Look  Results-  Results  of  the  Baseline/Comparison 
Quick-Look  Analysis  determining  if  additional  Baseline/Comparison  Case  Data 
Production  Runs  are  required. 

Baseline/Comparison  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S 
System  for  all  combinations  of  variables  and  scenario  excursions  for  the 
Baseline/Comparison  Case  as  directed  in  the  Experiment  Plan. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.2.4  Refine  Baseline/Comparison  Input  Data 

Identifying  input  parameters  for  the  next  Baseline/Comparison  Case  Experiment  Data 
Production  Run  (Figure  A-A5.2.2(d)). 


Facility 


Figure  A-A5.2.2(d)  Perform  Baseline/Comparison  Case  Runs 
Inputs: 

Baseline/Comparison  Quick  Look  Results-  List  results  of  the  Baseline/Comparison 
Quick-Look. 
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Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Next  Run  Input  Data  -  List  of  input  data  for  the  next  Baseline/Comparison  Case  Data 
Production  Run. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.3  Perform  Excursion  Case  Runs 

Conducting  initial  experiment  Excursion  Case  Runs  in  accordance  with  the  Experiment 
Plan  and  Experiment  Execution  CONOPS  using  the  Integrated  M&S  System  (Figure  A- 
A5.2(c)). 


Facility 


Figure  AA5.2(c)  Execute  Experiment 


Inputs: 

Baseline/Comparison  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S 
System  for  all  combinations  of  variables  and  scenario  excursions  for  the 
Baseline/Comparison  Case  as  directed  in  the  Experiment  Plan. 

Experiment  Execution  Plan  -  Document  that  defines  how  the  execution  of  the 
experiment  will  be  conducted. 


MTS  Technologies,  Inc. 


246 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Operator  Procedures  -  Procedures  used  by  M&S  operators  during  experiment 
execution. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Excursion  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S  System  for 
all  combinations  of  variables  and  scenario  variations  for  all  experiment  excursion 
cases  as  directed  in  the  Experiment  Plan. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.3.1  Review  Input  Data  for  Excursion  Cases 

Reviewing  and  fine-tuning  Excursion  Case  input  Data  (Figure  A-A5.2.3(a)). 


Experiment  Plan 


Facility 


Figure  AA5.2.3(a)  Perform  Excursion  Case  Runs 


Inputs: 

Experiment  Execution  Plan  -  Document  that  defines  how  the  execution  of  the 
experiment  will  be  conducted. 

Experiment  Execution  CONOPS  -  The  concept  of  operations  for  experiment 
scheduling  and  execution. 

Baseline/Comparison  Case  Data-  Experiment  data  produced  by  the  Integrated  M&S 
System  for  all  combinations  of  variables  and  scenario  excursions  for  the 
Baseline/Comparison  Case  as  directed  in  the  Experiment  Plan. 
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Next  Run  Excursion  Input  Data  -  List  of  input  data  for  the  next  Excursion  Case  Data 
Production  Run. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Reviewed  Excursion  Data  Inputs  -  List  of  input  parameters  for  an  Excursion  Case 
Data  Production  Run. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.3.2  Execute  Excursion  M&S  Run 

Perform  Excursion  Data  Production  Run  using  the  Integrated  M&S  System  in  accordance 
with  the  Experiment  Plan  and  Experiment  Execution  CONOPS  (Figure  A-A5.2.3(b)). 
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Figure  AA5.2.3(b)  Perform  Excursion  Case  Runs 


Inputs: 

Reviewed  Excursion  Data  Inputs  -  List  of  input  parameters  for  an  Excursion  Case 
Data  Production  Run. 

Tested  M&S  Environment  -  Integrated  System  after  full  testing. 

Operator  Procedures  -  Procedures  used  by  M&S  operators  during  experiment 
execution. 
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Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Excursion  Run  Output  Data  -  Data  resulting  from  the  Excursion  Data  Production 
Run. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.3.3  Perform  Excursion  Quick-Look  Data  Analysis 

Reviewing  the  output  data  from  each  Excursion  Case  Data  Production  Run  by  analysts 
and  M&S  personnel  to  determine  if  experiment  data  requirements  have  been  met  for  the 
Excursion  Case  and  to  determine  if  subsequent  data  production  runs  are  required  (Figure 
A-A5.2.3(c)). 


Experiment  Plan 


Facility 


Figure  AA5.2.3(c)  Perform  Excursion  Case  Runs 


Inputs: 

Excursion  Run  Output  Data  -  Data  resulting  from  the  Excursion  Run. 
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Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  meastres  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Excursion  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S  System  for 
all  combinations  of  variables  and  scenario  variations  for  all  experiment  excursion 
cases  as  directed  in  the  Experiment  Plan. 

Excursion  Quick-Look  Results  -  Results  of  the  Excursion  Case  Quick-Look  Analysis 
determining  if  additional  Excursion  Case  Data  Production  Runs  are  required. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.2.3.4  Refine  Excursion  Input  Data 

Identifying  input  parameters  for  the  next  Excursion  Case  Experiment  Data  Production  Run 
(Figure  A-A5.2.3(d)). 


Figure  AA5.2.3(d)  Perform  Excursion  Case  Runs 


Inputs: 

Excursion  Quick-Look  Results  -  Results  of  the  Excursion  Case  Quick-Look  Analysis 
determining  if  additional  Excursion  Case  Data  Production  Runs  are  required. 
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Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Next  Run  Excursion  Input  Data  -  List  of  Input  Data  for  the  next  Excursion  Case  Data 
Production  Run. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Facility  -  Buildings  and  equipment  necessary  to  support  personnel  and  tools  in  the 
conduct  of  the  activities. 
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A5.3  Review  Experiment  Data 

Reviewing  all  data  from  Baseline/Comparison  Case  and  Excursion  Case  Data  Production 
Runs  and  comparing  the  results  with  the  Experiment  Plan  and  Execution  CONOPS  to 
ensure  all  required  experiment  data  have  been  produced  (Figure  A-A5(c)). 


'****■'  Facility 


Figure  AA5(c)  Conduct  Experiment 


Inputs: 

Baseline/Comparison  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S 
System  for  all  combinations  of  variables  and  scenario  excursions  for  the 
Baseline/Comparison  Case  as  directed  in  the  Experiment  Plan. 

Excursion  Case  Data  -  Experiment  data  produced  by  the  Integrated  M&S  System  for 
all  combinations  of  variables  and  scenario  variations  for  all  experiment  excursion 
cases  as  directed  in  the  Experiment  Plan. 
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Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  performance  and  effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Experiment  Data  -  Results  of  the  experiment  for  all  parts  of  the  experiment  as 
directed  by  the  Experiment  Plan.  Includes  performance  and  cost  data  for  the 
Baseline/Comparison  Case  and  each  Experiment  Excursion. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analyse  environments. 
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A6  Develop  Trade  Study 

Producing  the  WARCON  product  that  presents  the  project  results  to  the  acquisition 
decision  maker.  The  Trade  Study  summarizes  project  data  and  presents  the  results  of  the 
performance-cost  trade-off  analysis  for  each  subject  system  improvement  option  analyzed 
using  the  Integrated  M&S  System  (Figure  A-AO(f)). 


Figure  A-AO(f)  Execute  WARCON  Process 


Inputs: 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 
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Experiment  Data  -  Results  of  the  experiment  for  all  parts  of  the  experiment  as 
directed  by  the  Experiment  Plan.  Includes  performance  and  cost  data  for  each 
experiment  excursion. 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 

Validation  and  Verification  Report  -  Results  and  assessment  based  on  the 
acceptability  criteria  that  the  built  system  is  validated  and  verified  given  the  intended 
use. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  Measures  of  Performance  and  Effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

Trade  Study  Report  -  The  primary  product  resulting  from  the  WARCON  process  to 
support  acquisition  decision  makers.  This  formal  report  summarizes  cost-performance 
trade-offs  among  the  different  options  for  future  weapon  system  designs. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A6.1  Analyze  Combined  Cost  Data 

Analyzing  the  combined  engineering  level  cost  data  (derived  from  conducting  experiment) 
and  any  external  data  needed  to  determine  Total  Ownership  Cost  (TOC)  for  each 
alternative  subject  system  design  (Figure  AA6(a)). 


Tools  (Analysis  Tools) 


Figure  AA6(a)  Develop  Trade  Study 


Inputs: 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

TOC  Data  -  External  financial  resource  data  required  to  support  the  WARCON 
process  regarding  equipping,  sustaining,  and  operating  military  forces  sufficient  to 
meet  national  goals. 
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Cost  Data  for  Alternative  Designs  -  Rough  order  of  magnitude  estimates  of 
acquisition  costs  in  relative  terms,  as  well  as  estimates  of  total  ownership  costs  of  the 
subject  concept  systems  under  study. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  Measures  of  Performance  and  Effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Project  Management  Plan  -  The  overall  direction  for  all  phases  of  the  WARCON 
process  to  include  tasks,  organization,  program  resources  and  costs,  software 
development,  products,  schedules  and  milestones.  The  Software  Development  Plan  is 
included  within  this  Plan. 

Outputs: 

TOC  Analysis  Results-  TOC  data  analysis  results  for  each  alternative  subject 
system  design. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A6.2  Analyze  Cost  and  Performance  Trade-Offs 

Comparing  TOC  and  performance  data  as  derived  from  Measures  of  Performance  and 
Effectiveness,  along  with  alternate  system  descriptions  and  parameters,  to  determine 
detailed  trade-offs  associated  with  each  alternate  system  design  (Figure  A-A6(b)). 


Tools  (Analysis  Tools) 


Figure  AA6(b)  Develop  Trade  Study 


Inputs: 

TOC  Analysis  Results-  TOC  data  analysis  results  for  each  alternative  subject 
system  design. 

Experiment  Data  -  Results  of  the  experiment  for  all  parts  of  the  experiment  as 
directed  by  the  Experiment  Plan.  Includes  performance  and  cost  data  for  each 
experiment  excursion. 
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Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 

Performance  Data  for  Alternative  Designs  -  Design  information  (design  concept, 
description  and  associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  Measures  of  Performance  and  Effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Trade  Study  Plan  -  Final  version  of  the  Draft  Trade  Study  Plan. 

Outputs: 

Cost  and  Performance  Trade-Off  Results  -  Trade-Off  analysis  results  for  use  in  the 
Trade  Study. 

Draft  Trade  Study  Recommendations  -  Ranking  of  system  designs  based  on  TOC 
and  performance  data  as  derived  from  Measures  of  Performance  and  Effectiveness. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 


MTS  Technologies,  Inc. 


263 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


A6.2.1  Assess  Quantitative  Trade-Offs 

Analyzing  and  comparing  the  quantitative  operational  performance  and  cost  data  for  each 
subject  system  improvement  option  analyzed  using  the  Integrated  M&S  System  (Figure  A- 
A6.2(a)). 


Tools  (Analysis  Tools) 


Figure  AA6.2(a)  Analyze  Cost  and  Performance  Trade-Offs 


Inputs: 

TOC  Analysis  Results-  TOC  data  analysis  results  for  each  alternative  subject 
system  design. 

Experiment  Data  -  Results  of  the  experiment  for  all  parts  of  the  experiment  as 
directed  by  the  Experiment  Plan.  Includes  performance  and  cost  data  for  each 
experiment  excursion. 
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Performance  Data  for  Alternative  Designs  -  Design  information  (design  concept, 
description  and  associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

System  Description/Information  -  Information  and  data  available  from  external 
sources  about  the  current  and  future  warfare  system  being  analyzed  that  is  required  to 
plan  and  perform  the  experiment  and  analysis. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  Measures  of  Performance  and  Effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Quantitative  Trade-Offs  Results  -  Summary  of  results  of  the  quantitative 
performance-cost  trade-off  analysis  for  the  subject  system  improvement  options. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A6.2.2  Assess  Qualitative  Trade-Offs 

Analyzing  and  comparing  the  non-quantitative  operational  performance  and  cost  factors 
and  considerations  for  each  subject  system  improvement  option  analyzed  (Figure  A 
A6.2(b)). 


Tools  (Analysis  Tools) 


Figure  AA6.2(b)  Analyze  Cost  and  Performance  Trade-Offs 


Inputs: 

Qualitative  Trade-Off  Results- Summary  of  analysis  of  the  comparison  of  non- 
quantitative  factors  and  considerations  for  the  subject  system  improvement  options. 

Performance  Data  for  Alternative  Designs  -  Design  information  (design  concept, 
description  and  associated  cost)  for  alternate  subject  system  designs  to  be  analyzed 
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System  Description/Information  -  Information  and  data  available  from  external 
sources  about  the  current  and  future  warfare  system  being  analyzed  that  is  required  to 
plan  and  perform  the  experiment  and  analysis. 

Controls: 

Experiment  Plan  -  Document  that  defines  the  experiment  approach,  objectives, 
hypotheses,  measures  of  Performance  and  Effectiveness  (MOPs/MOEs),  analysis 
methods,  data  extraction  and  collection  requirements,  scenarios,  and  explicit 
procedures  for  conducting  the  experiment. 

Outputs: 

Qualitative  Trade-Off  Results  -  Summary  of  analysis  of  the  comparison  of  non- 
quantitative  factors  and  considerations  for  the  subject  system  improvement  options. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A6.2.3  Perform  Integrated  Trade-Off  Analysis 

Combining  and  analyzing  the  quantitative  and  qualitative  trade-off  analysis  data  and 
factors  for  the  subject  system  improvement  options  (Figure  A-A6.2(c)). 


Tools  (Analysis  Tools) 


Figure  AA6.2(c)  Analyze  Cost  and  Performance  Trade-Offs 


Inputs: 

Qualitative  Trade-Off  Results  -  Summary  of  analysis  of  the  comparison  of  non- 
quantitative  factors  and  considerations  for  the  subject  system  improvement  options. 

Quantitative  Trade-Offs  Results  -  Summary  of  results  of  the  quantitative 
performance-cost  trade-off  analysis  for  the  subject  system  improvement  options. 
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Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Outputs: 

Cost  and  Performance  Trade-Off  Results  -  Summary  of  combined  and  integrated 
trade-off  analysis  results. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A6.2.4  Formulate  Draft  Trade-Off  Study  Recommendations 

Developing  Trade  Study  recommendations  based  on  the  integrated  trade-off  analysis 
(Figure  A-A6.2(d)). 


Tools  (Analysis  Tools) 


Figure  AA6.2(d)  Analyze  Cost  and  Performance  Trade-Offs 


Inputs: 

Cost  and  Performance  Trade-Off  Results  -  Summary  of  combined  and  integrated 
trade-off  analysis  results. 

Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 
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Outputs: 

Draft  Trade  Study  Recommendations  -  Draft  recommendations  for  the  Trade  Study 
derived  from  the  integrated  trade-off  analysis  of  subject  system  options. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A6.3  Formulate  Draft  Trade  Study 

Reviewing  the  Customer  Problem  Statement  and  synthesizing  trade-off  analysis  results  to 
formulate  a  concise  summary  to  document  WARCON  project  results  for  customer  review 
(Figure  A-A6(c)). 


Tools  (Analysis  Tools) 


Figure  A-A6(c)  Develop  Trade  Study 


Inputs: 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 

System  Description/Information  -  Information  and  data  available  from  external 
sources  about  the  current  and  future  warfare  system  being  analyzed  that  is  required  to 
plan  and  perform  the  experiment  and  analysis. 
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Cost  and  Performance  Trade-Off  Results  -  Trade-Off  analysis  results  for  use  in  the 
Trade  Study. 

Draft  Trade  Study  Recommendations  -  Draft  recommendations  for  the  Trade  Study 
derived  from  the  integrated  trade-off  analysis  of  subject  system  options. 

Validation  and  Verification  Report  -  Results  and  assessment  based  on  the 
acceptability  criteria  that  the  built  system  is  validated  and  verified  given  the  intended 
use. 

Performance  Data  for  Alternative  Designs  -  Design  information  (design  concept, 
description  and  associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Outputs: 

Draft  Trade  Study  -  Document  presenting  the  Trade  Study  and  results  for  customer 
review. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 
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A6.3.1  Review  Customer  Problem  Statement 

Reviewing  the  customer  problem  statement  and  interpreting  trade-off  analysis  results  in 
the  context  of  the  original  Customer  Problem  Statement  (Figure  A-A6.3(a)). 


Tools  (Analysis  Tools) 


Figure  AA6.3(a)  Formulate  Draft  Trade  Study 


Inputs: 

Customer  Problem  Statement  -  Tasking  from  the  customer  that  defines  the 
acquisition  decision  that  application  of  the  WARCON  process  will  support 
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Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Outputs: 

Customer  Problem  Review  -  Results  of  interpreting  trade-off  analysis  results  in  the 
context  of  the  original  Customer  Problem  Statement  and  producing  concise  summary 
to  document  final  project  results. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 


MTS  Technologies,  Inc. 


275 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


A6.3.2  Summarize  Subject  System  Design  information 

Summarizing  aspects  of  descriptive  information  and  data  and  for  subject  system  designs 
relevant  for  inclusion  in  the  Draft  Trade  Study  (Figure  A-A6.3(b)). 


Tools  (Analysis  Tools) 


Figure  AA6.3(b)  Formulate  Draft  Trade  Study 


Inputs: 

Customer  Problem  Review-  Results  of  interpreting  trade-off  analysis  results  in  the 
context  of  the  original  customer  problem  statement  and  producing  concise  summary  to 
document  final  project  results. 

Subject  System  Description/Information  -  Information  and  data  available  from 
external  sources  about  the  current  and  future  warfare  system  being  analyzed  that  is 
required  to  plan  and  perform  the  experiment  and  analysis. 
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Performance  Data  for  Alternative  Designs  -  Design  information  (design  concept, 
description  and  associated  cost)  for  alternate  subject  system  designs  to  be  analyzed. 

Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Outputs: 

Alternative  Design  Information  -  Summarized  design  description  information  and 
data  for  alternative  subject  system  design  options. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 

Tools  -  Previously  validated  methods,  models  and  simulations  that  support  the 
modeling  and  analysis  environments. 


MTS  Technologies,  Inc. 


277 


FOR  OFFICIAL  USE  ONLY 


FOR  OFFICIAL  USE  ONLY 


A6.3.3  Summarize  Integrated  Trade-Off  Analysis  and  Recommendations 

Preparing  a  written  summary  of  Trade  Study  analysis  and  recommendations  for  inclusion 
in  the  Draft  Trade  Study  (Figure  A-A6.3(c)). 


Tools  (Analysis  Tools) 


Figure  AA6.3(c)  Formulate  Draft  Trade  Study 


Inputs: 

Alternative  Design  Information  -  Summarized  design  description  information  and 
data  for  alternative  subject  system  design  options. 

Cost  and  Performance  Trade-Off  Results  -  T rade-Off  analysis  results  for  use  in  the 
T rade  Study. 
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Draft  Trade  Study  Recommendations  -  Draft  recommendations  for  the  Trade  Study 
derived  from  the  integrated  trade-off  analysis  of  subject  system  options. 

Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Outputs: 

Trade-Off  Analysis  Summary- Written  summary  of  Trade  Study  analysis  and 
recommendations  for  inclusion  in  the  Draft  Trade  Study. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A6.3.4  Write  Draft  Trade  Study 

Writing  a  concise  summary  of  all  components  of  Trade  Study  background,  analysis  and 
recommendations  into  a  draft  Trade  Study  document  for  customer  review  (Figure  A- 
A6.3(d)). 


Tools  (Analysis  Tools) 


Figure  A-A6.3(d)  Formulate  Draft  Trade  Study 


Inputs: 

Trade-Off  Analysis  Summary- Written  summary  of  Trade  Study  analysis  and 
recommendations  for  inclusion  in  the  Draft  Trade  Study. 

Alternative  Design  Information  -  Summarized  design  description  information  and 
data  for  alternative  subject  system  design  options. 
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Customer  Problem  Review  -  Results  of  interpreting  trade-off  analysis  results  in  the 
context  of  the  original  Customer  Problem  Statement  and  producing  concise  summary 
to  document  final  project  results. 

Validation  and  Verification  Report  -  Results  and  assessment  based  on  the 
acceptability  criteria  that  the  built  system  is  validated  and  verified  given  the  intended 
use. 

Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Outputs: 

Draft  Trade  Study-  Draft  document  presenting  the  Trade  Study  results  for  customer 
review. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A6.4  Perform  Customer  Trade  Study  Review 

Meeting  with  the  customer  to  review  the  Draft  Trade  Study  and  to  discuss  customer 
comments  and  recommendations  (Figure  A-A6(d)). 


Tools  (Analysis  Tods) 


Figure  AA6(d)  Develop  Trade  Study 


Inputs: 

Draft  Trade  Study  -  Document  presenting  the  Trade  Study  and  results  for  customer 
review. 

Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 
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Outputs: 

Customer  Trade  Study  Review  Comments  -  Comments  received  from  the  customer 
during  the  review  process. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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A6.5  Prepare  Trade  Study  Report 

Incorporating  customer  comments  and  recommendations  into  the  draft  Trade  Study  to 
prepare  the  final  Trade  Study  Report  (Figure  A-A6(e)). 


Tools  (Analysis  Tools) 


Figure  A-A6(e)  Develop  Trade  Study 


Inputs: 

Customer  Trade  Study  Review  Comments  -  Comments  received  from  the  customer 
during  the  review  process. 

Draft  Trade  Study-  Draft  document  presenting  the  Trade  Study  results  for  customer 
review. 
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Controls: 

Trade  Study  Plan  -  Document  that  defines  the  approach,  methods,  and  performance 
measures  to  be  used  to  assess  trade-offs  among  alternate  weapon  system  designs 
and  total  ownership  costs. 

Outputs: 

Trade  Study  Report  -  The  primary  product  resulting  from  the  WARCON  process  to 
support  acquisition  decision  makers.  This  formal  report  summarizes  cost-performance 
trade-offs  among  the  different  options  for  future  weapon  system  designs. 

Mechanisms: 

Personnel  -  Government,  contract  employees,  subject  matter  experts,  systems 
engineers  and  analysts  available  to  support  using  the  WARCON  process. 
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